kube-scan 和 KCCSS

2020 年 3 月 10 日
筆記

在 Kubernetes 中使用聲明式 API 來定義工作負載，因為工作負載的靈活多變，這種定義的隨意性是很大的，很容易因為複製黏貼、手工運維等原因給 Pod 分配不需要的特權，造成安全隱患。kube-scan 就是針對這種情況而出現的一個工具，它根據內置的二十幾個檢查項目，對工作負載描述的安全性進行打分，從最安全的 0 分，到最危險的 10 分。

kube-scan 所使用的計分項和演算法，被稱為 Kubernetes Common Configuration Scoring System (KCCSS)，是一套仿造 CVSS 的 Kubernetes 配置評分系統，它從對完整性、可用性和保密性三個方面的威脅來評價安全漏洞，評分標準對降低工作負載安全性的評價，如果在同樣方面已經做出了合適的補救措施，還可以挽回這部分的扣減。

快速開始

老一套的部署方式：

$ kubectl apply -f       https://raw.githubusercontent.com/octarinesec/kube-scan/master/kube-scan.yaml  namespace/kube-scan created  configmap/kube-scan created  serviceaccount/kube-scan created  clusterrole.rbac.authorization.k8s.io/kube-scan created  clusterrolebinding.rbac.authorization.k8s.io/kube-scan created  deployment.apps/kube-scan created  service/kube-scan-ui created

可以看到創建了一個新的命名空間 kube-scan，其中有一個 kube-scan-ui:80 的服務。嘗試訪問一下，頁面會顯示出當前集群中運行的有風險載荷，例如使用 Helm 預設安裝的 Traefik：

點擊 show more，會顯示對應問題的詳細資訊：

往前一步

通過對部署文件的觀察，會發現這個 Pod 里有兩個容器，分別命名為 kube-scan-ui 和 kube-scan，粗淺判斷這是一個前後端分離的任務。在瀏覽器中打開調試工具，會發現對 <host-name>/api/risks 的訪問，直接訪問這個地址，會拿到一個 JSON 響應：

{      "data": [{          "kind": "Deployment",          "name": "traefik-1583034161",          "namespace": "infra",          "domain": "",          "risk": {              "riskScore": 7,              "riskCategory": "Medium",              "riskItems": [{                      "name": "AllowPrivilegeEscalation",                      "riskCategory": "Low",                      "type": "Basic",                      "title": "Workload allows privilege escalation",                      "shortDescription": "Privilege escalation allows programs inside the container to run as root",                      "description": "Privilege escalation allows programs inside the container to run as root, even if the main process is not root, which can give those programs control over that container, host and even cluster",                      "confidentiality": "Low",                      "confidentialityDescription": "Root processes that can escape the containers have the ability to read secrets from Kubernetes, Docker and other applications",

這樣一來，我們就可以考慮，將 UI 部分去掉，僅留下後端服務。如此一來，就可以通過簡單的程式碼，把掃描過程集成到日常運維工作之中了。

另外一些小秘密

kube-scan 的文檔非常貧瘠，因此只能從 YAML 和源碼中找到一些東西。

刷新時間

YAML 中有一個環境變數 KUBESCAN_REFRESH_STATE_INTERVAL_MINUTES，原定的刷新時間是 1440 分鐘也就是 24 小時。修改這一變數就能進行更快的刷新了。

KCCSS 配置

安裝過程中生成了一個 Configmap 對象 kube-scan，其中保存了 kube-scan 的評價標準，在他的程式碼中可以看到已經支援的各種威脅和補救措施。basic 節點中列出了目前能夠判斷的威脅列表，例如下面的定義：

- name: "privileged"    title: "Workload is privileged"    shortDescription: "Processes inside a privileged containers get full access to the host"    description: "..."    confidentiality: "High"    confidentialityDescription: "..."    integrity: "Low"    integrityDescription: "..."    availability: "Low"    availabilityDescription: "..."    exploitability: "Moderate"    attackVector: "Local"    scope: "Host"    handler: "IsPrivileged"

其中有一些非常易讀的關鍵資訊，例如問題的名稱、標題、描述，以及對完整性、可用性和保密性的影響級別，最後是攻擊來源、難度和範圍。

評分方法

定時對工作負載進行檢查，然後調用源碼 formula.go 中實現的評分過程，整體流程如下：

GetHandler 根據配置文件中的 handler 欄位獲取處理方法。
用查詢到的 Handler 函數對工作負載進行檢查，如果存在該問題，則根據問題涉及範圍，檢查該工作負載是否已經有針對性的進行了加固，以此來調整該項目得分。
根據 Risk 和 Remediation 生成結果列表。

注意如下命名空間是硬編碼忽略的 {「octarine」, 「kube-system」, 「kube-public」, 「octarine-tiller」, 「istio-system」, 「octarine-dataplane」, 「kube-scan」}

結論

KCCSS 和 kube-scan 兩個項目的文檔都非常稀少，很不友好。
特徵庫更新困難，需要同時更新源碼和配置。
僅提供了對全集群進行掃描，如果能加入單個對象進行檢查的手段可能會更加實用。