2024年09月14日玄貓（BlackCat）

Kubernetes叢集防禦攻擊策略

本文探討如何強化 Kubernetes 叢集的安全性，涵蓋組態、建置、佈署和執行時四大導向。從組態 Kubernetes 元件、強化映像安全到使用准入控制器和執行時監控，提供全面的防禦策略，並深入解析路徑遍歷漏洞 CVE-2019-11246 等實際案例，提供緩解方案和最佳實務建議，以降低叢集受攻擊風險。

資安系統設計

Kubernetes 叢集安全 CVE 漏洞修補 RBAC 准入控制器

Kubernetes 叢集的安全性至關重要，需要多層次的防禦策略。本文除了探討叢集組態、建置、佈署和執行時的安全強化方法外，也深入分析了 CVE-2019-11246 等路徑遍歷漏洞的成因、影響和緩解措施。透過正確組態 RBAC、網路策略、安全上下文，並結合映像掃描、資源監控及稽核日誌等機制，可以有效降低 Kubernetes 叢集的攻擊面，提升整體安全性。同時，持續更新 Kubernetes 版本和相關工具，並使用 kube-hunter 等安全掃描工具，能有效防範已知漏洞，確保叢集的穩定執行。

防禦攻擊

在本文中，我們將討論如何透過保護 Kubernetes 群集來防禦各種攻擊。主要的四個防禦領域是 Kubernetes 群集組態、構建、佈署和執行時。

保護 Kubernetes 群集組態

有多種方法可以組態 Kubernetes 群集，例如 kops 和 kubeadm。無論使用哪種工具來組態群集，每個 Kubernetes 元件都需要安全地組態。使用 kube-bench 對 Kubernetes 群集進行基準測試並改進安全組態。確保啟用 RBAC，停用 --anonymous-auth 標誌，加密網路連線等。

主要防禦措施包括：

正確組態 Kubernetes 控制平面、kubelet 等的身份驗證和授權。
保證 Kubernetes 元件之間的通訊安全，例如 kube-apiserver、kubelet 和 etcd 之間的通訊。
為 etcd 啟用靜態資料加密。
確保不啟動不必要的元件，例如儀錶板。
確保啟用所有必要的准入控制器，同時停用已棄用的控制器。

內容解密：

這些措施可以顯著提高 Kubernetes 群集的安全性，防止各種攻擊。

加強 Kubernetes 叢集的防禦措施

在安全地佈建 Kubernetes 叢集之後，駭客入侵叢集的機會大大減少，就像之前特斯拉叢集因儀錶板未要求身份驗證而被攻擊的案例一樣。接下來，我們將討論如何加強建置過程的安全性。

加強建置過程的安全性

加強 Kubernetes 叢集的安全性也包括加強微服務的安全性。微服務的安全性必須從 CI/CD 管道的開始階段就予以確保。以下是一些關鍵的對策，正如第 8 章《保護 Kubernetes Pods 的安全》和第 9 章《DevOps 管道中的映像掃描》所討論的那樣：

適當地解決映像掃描工具發現的漏洞，以減少透過利用應用程式漏洞成功入侵的可能性。
對 Dockerfile 進行基準測試，以改善映像的安全性組態。確保映像中不儲存敏感資料，所有依賴的套件都是最新的，等等。
掃描映像中的可執行檔，以確保映像中沒有植入惡意軟體。
正確組態 Kubernetes 的安全上下文，以遵循最小許可權原則，限制對系統資源的存取，例如使用主機層級的名稱空間、主機路徑等，並移除不必要的 Linux 功能，只授予必要的功能。
不要啟用自動掛載服務帳戶。如果工作負載不需要服務帳戶，則不要為其建立服務帳戶。
遵循最小許可權原則，瞭解工作負載正在執行的任務，並只授予服務帳戶所需的許可權。
遵循最小許可權原則，估計工作負載的資源使用情況，並對工作負載應用適當的資源請求和限制。

當然，加強建置過程的安全性也可以擴充套件到整個 CI/CD 管道的安全性，例如原始碼管理和 CI/CD 元件。然而，這超出了本文的範圍。我們將只建議與加強 Kubernetes 叢集安全性最相關的選項。接下來，我們將討論如何加強佈署的安全性。

加強佈署的安全性

我們已經在第 7 章《身份驗證、授權和准入控制》和第 8 章《保護 Kubernetes Pods 的安全》中討論了 Kubernetes 叢集中的不同型別的准入控制器，以及使用它們的必要性。使用准入控制器和其他內建機制可以作為工作負載的一個很好的安全門衛。以下是一些關鍵的對策：

對名稱空間和工作負載應用網路策略。這可以限制對工作負載的存取（入站網路策略）或實施最小許可權原則（出站網路策略）。當給定一個工作負載時，如果知道出站連線的目的地 IP 位址區塊，則應該為該工作負載建立一個網路策略，以限制其出站連線。出站網路策略應該阻止任何目的地超出白名單 IP 位址區塊的流量，例如從命令和控制伺服器下載加密貨幣挖礦二進位檔案。
使用 Open Policy Agent（OPA）來確保只允許來自受信任映像登入檔的映像在叢集中執行。使用此策略，OPA 應該阻止任何來自不受信任來源的映像執行。例如，包含加密貨幣挖礦二進位檔案的惡意映像可能存在於 Docker Hub 中，因此不應將 Docker Hub 視為受信任的映像登入檔。
使用映像掃描准入控制器來確保只允許符合掃描策略的映像在叢集中執行。正如第 9 章《DevOps 管道中的映像掃描》中所討論的那樣，在佈署工作負載時可能會發現新的漏洞，並且漏洞資料函式庫將被更新。因此，在佈署之前進行掃描是必要的。
使用 OPA 或 Pod 安全策略來確保工作負載具有有限的 Linux 功能和受限制的對主機層級名稱空間、主機路徑等的存取。
最好在工作節點上啟用 AppArmor，並為每個佈署的映像應用 AppArmor 組態檔。在工作負載佈署時會套用 AppArmor 組態檔，儘管實際的保護發生在執行時。一個好的使用案例是建立一個 AppArmor 組態檔，以將允許的程式加入白名單，當您知道容器內執行的程式時，以便其他程式（如加密貨幣挖礦程式）將被 AppArmor 阻止。

利用准入控制器的強大功能，為您的工作負載佈署建立一道安全門。接下來，我們將討論如何在執行時加強工作負載的安全性。

加強執行時的安全性

您的 Kubernetes 叢集很可能是抵禦駭客攻擊的前線戰場。儘管我們討論了不同的策略來加強建置和佈署的安全性，但所有這些策略最終都旨在減少 Kubernetes 叢集中的攻擊面。您不能只是閉上眼睛，假設 Kubernetes 叢集中的一切都會正常運作。這就是為什麼我們在第 10 章《Kubernetes 叢集的即時監控和資源管理》和第 11 章《縱深防禦》中討論了資源監控、稽核、秘密管理、偵測和數位鑑識。以下是加強執行時安全性的關鍵對策：

資源監控與稽核

佈署像 Prometheus 和 Grafana 這樣的監控工具來監控 Kubernetes 叢集中的資源使用情況。這對於確保服務的可用性和檢測加密貨幣挖礦等攻擊至關重要，因為這些攻擊可能會觸發 CPU 使用率的激增。
啟用 Kubernetes 的稽核政策來記錄 Kubernetes 事件和活動。

高用性和安全管理

確保基礎架構、Kubernetes 元件和工作負載的高用性。
使用像 Vault 這樣的秘密管理工具來管理和提供微服務的秘密。

異常檢測與數位鑑識

佈署像 Falco 這樣的檢測工具來檢測 Kubernetes 叢集中的可疑活動。
最好擁有數位鑑識工具來收集和分析可疑事件。

您可能會注意到，我們沒有提到保護微服務之間的通訊。服務網格是一個熱門話題，可以幫助保護微服務之間的通訊。然而，服務網格並未在本文中涵蓋，原因有二：

效能開銷：服務網格會為工作負載和 Kubernetes 叢集帶來效能開銷，因此它們還不是保護服務之間通訊的完美解決方案。
應用程式安全性：從應用程式安全的角度來看，很容易強制服務監聽埠 443，並使用 CA 簽署的憑證進行加密通訊。如果微服務還執行身份驗證和授權，那麼只有受信任的微服務才能存取授權資源。因此，服務網格並不是保護服務之間通訊的不可取代的解決方案。

要抵禦對 Kubernetes 叢集的攻擊，我們需要從端對端地加強 Kubernetes 叢集的佈建、建置、佈署和執行時安全性。它們都應該被視為同等重要，因為您的防禦能力取決於您最薄弱的環節。

從 Kubernetes CVEs 中學習

常見漏洞與暴露（CVEs）簡介

常見漏洞與暴露（Common Vulnerabilities and Exposures, CVEs）是用於標識流行應用程式中公開已知的安全漏洞和暴露的識別碼。CVE ID 由 CVE 字串、年份和漏洞的 ID 號組成。CVE 資料函式庫由 MITRE Corporation 維護，公開可用。CVE 條目包括每個問題的簡要描述，有助於瞭解問題的根本原因和嚴重性，但不包含技術細節。這些資訊對 IT 專業人員協調和優先更新至關重要。每個 CVE 都有一個與之相關的嚴重性評級，MITRE 使用通用漏洞評分系統（Common Vulnerability Scoring System, CVSS）來分配 CVE 的嚴重性評級。建議立即修補高嚴重性的 CVE。

CVE 條目範例

在 cve.mitre.org 上可以看到 CVE 條目的範例。如下圖所示，一個 CVE 條目包括 ID、簡要描述、參考資料、CVE 編號授權機構（CNA）的名稱以及條目建立日期。

圖 13.1 – MITRE 對 CVE-2018-18264 的條目

此圖示顯示了 CVE 條目的結構，包括其主要組成部分。

對於安全研究人員和攻擊者來說，CVE 條目中最有趣的部分是參考資料部分。CVE 的參考資料是研究人員發表的部落格連結，涵蓋了問題的技術細節，以及問題描述和提取請求的連結。安全研究人員研究這些參考資料以瞭解漏洞並開發類別似問題或尚未修復的已知問題的緩解措施。另一方面，攻擊者研究這些參考資料以找到未修補的變體。

本章重點

重點整理

瞭解 CVEs 的定義和重要性
瞭解如何檢視 CVE 條目及其組成部分
分析四個公開已知的 Kubernetes 安全漏洞及其緩解策略
瞭解如何使用 kube-hunter 掃描 Kubernetes 叢集中的已知安全漏洞

緩解策略與未來工作

為了保護 Kubernetes 叢集免受已知和未知漏洞的影響，建議採取以下措施：

升級到最新版本：定期檢查並升級到最新版本的 Kubernetes 和相關工具，如 kubectl。
使用安全掃描工具：利用 kube-hunter 等工具定期掃描叢集中的已知安全漏洞。
加強叢集組態：根據最佳實踐組態叢集，包括網路策略、RBAC 設定等。
持續監控：實施持續監控機制，以便及時發現和回應潛在的安全問題。

kube-hunter 簡介

kube-hunter 是一款開源工具，用於掃描 Kubernetes 叢集中的已知安全漏洞。它可以幫助叢集管理員發現潛在的安全風險，並採取相應的措施進行緩解。

進一步閱讀

Kubernetes 中的路徑遍歷問題：CVE-2019-11246

問題背景

在 Kubernetes 中，開發者經常需要將檔案複製到容器中或從容器中複製出來以進行除錯。kubectl cp 命令允許開發者在 Pod 中的容器之間複製檔案。預設情況下，這個操作是在 Pod 中的第一個容器上執行的。

漏洞細節

在 2018 年，研究人員發現了一個漏洞，允許攻擊者利用 kubectl cp 命令覆寫客戶端主機上的檔案。攻擊者可以存取 Pod 並修改 TAR 檔案，使其包含特殊檔案，這些檔案使用相對路徑來覆寫主機上的檔案。當這個被篡改的 TAR 檔案被複製到主機並解壓縮時，它可能會覆寫主機上的檔案，導致資料洩露和程式碼執行。

漏洞範例

假設攻擊者修改了 TAR 檔案，使其包含兩個檔案：regular.txt 和 foo/../../../../bin/ps。其中 regular.txt 是使用者預期的檔案，而 ps 是一個惡意的二進位檔案。如果這個 TAR 檔案被複製到 /home/user/admin，惡意的二進位檔案可能會覆寫 /bin 資料夾中的知名 ps 二進位檔案。

緩解策略

為了強化叢集對此問題和其他類別似 CVE-2019-11246 的問題，可以採取以下策略：

始終使用最新版本的 kubectl：可以透過以下命令找到最新版本的 kubectl 二進位檔案：
```
$ curl https://storage.googleapis.com/kubernetes-release/release/stable.txt
v1.18.3
```

使用准入控制器限制 kubectl cp 的使用：可以使用 Open Policy Agent 作為准入控制器。下面是一個拒絕 kubectl cp 命令的策略：

deny[reason] {
  input.request.kind.kind == "PodExecOptions"
  input.request.resource.resource == "pods"
  input.request.subResource == "exec"
  input.request.object.command[0] == "tar"
  reason = sprintf("kubectl cp was detected on %v/%v by user: %v", [
    input.request.namespace,
    input.request.object.container,
    input.request.userInfo.username])
}

這個策略透過禁止在 Pod 中執行 TAR 二進位檔案來停用 kubectl cp。

對客戶端套用適當的存取控制：如果您是生產叢集的管理員，您的工作機器上可能有很多秘密，攻擊者可能會想要存取這些秘密。最好使用專用的硬體來存取 Kubernetes 叢集，並確保建置機器上的敏感資料有適當的存取控制。
為所有 Pod 設定安全上下文：確保 Pod 使用 readOnlyRootFilesystem，這將防止檔案被篡改：
```
spec:
  securityContext:
    readOnlyRootFilesystem: true
```

使用 Falco 規則偵測檔案修改：

偵測二進位檔案在 Pod 中的修改：使用 Write below monitored dir 規則來偵測對 TAR 二進位檔案的更改。

- rule: Write below monitored dir
  desc: an attempt to write to any file below a set of binary directories
  condition: >
    evt.dir = < and open_write and monitored_dir
    and not package_mgmt_procs
    and not coreos_write_ssh_dir
    and not exe_running_docker_save
    and not python_running_get_pip
    and not python_running_ms_oms
    and not google_accounts_daemon_writing_ssh
    and not cloud_init_writing_ssh
    and not user_known_write_monitored_dir_conditions
  output: >
    File below a monitored directory opened for writing
    (user=%user.name command=%proc.cmdline file=%fd.name parent=%proc.pname pcmdline=%proc.pcmdline gparent=%proc.aname[2]
    container_id=%container.id image=%container.image.repository)
  priority: ERROR
  tags: [filesystem, mitre_persistence]

偵測易受攻擊的 kubectl 版本的使用：使用以下規則來偵測易受攻擊的 kubectl 版本。

- macro: safe_kubectl_version
  condition: (jevt.value[/userAgent] startswith "kubectl/v1.15" or
              jevt.value[/userAgent] startswith "kubectl/v1.14.3" or
              jevt.value[/userAgent] startswith "kubectl/v1.14.2" or
              jevt.value[/userAgent] startswith "kubectl/v1.13.7" or
              jevt.value[/userAgent] startswith "kubectl/v1.13.6" or
              jevt.value[/userAgent] startswith "kubectl/v1.12.9")
- rule: K8s Vulnerable Kubectl Copy
  desc: Detect any attempt vulnerable kubectl copy in pod
  condition: kevt_started and pod_subresource and kcreate and ka.target.subresource = "exec" and ka.uri.param[command] = "tar" and not safe_kubectl_version
  output: Vulnerable kubectl copy detected (user=%ka.user.name pod=%ka.target.name ns=%ka.target.namespace action=%ka.target.subresource command=%ka.uri.param[command] userAgent=%jevt.value[/userAgent])
  priority: WARNING
  source: k8s_audit
  tags: [k8s]