Kubernetes安全攻防：安全建議與最佳實踐

– 19 分鐘閱讀

根據上述安全風險，我建議遵循以下最佳實踐來保護 Kubernetes 環境：

  1. 避免使用環境變數掛載 Secrets：始終使用檔案掛載方式，這樣可以確保 Secrets 在更新時自動同步，並減少暴露風險

  2. 限制容器掛載點：稽核所有容器掛載點，特別注意高風險掛載如 Docker socket、服務帳號令牌和可寫入主機目錄

  3. 實施最小許可權原則：為服務帳號分配最小必要許可權，使用 RBAC 嚴格控制存取許可權

  4. 定期輪換 Secrets：建立自動輪換機制，確保即使憑證洩漏，其有效期也是有限的

  5. 監控異常存取：實施監控系統，檢測對敏感掛載點和 Secrets 的異常存取模式

  6. 使用安全上下文：為 Pod 和容器設定適當的安全上下文，限制容器內的許可權

  7. 避免特權容器：除非絕對必要，否則不要使用特權容器，因為它們可以繞過大多數容器安全限制

在容器安全領域，我發現預防永遠優於檢測和回應。透過正確設定 Secrets 管理和掛載策略，可以顯著降低容器逃逸和憑證洩漏的風險。

CSI（容器儲存介面）和主機檔案系統掛載都存在安全風險，特別是當其他人可以存取它們時。在設計容器化應用程式時，應該始終考慮這些風險，並實施適當的緩解措施。

在容器安全的世界中，最小化攻擊面是關鍵。每個容器應該只包含其執行所必需的內容，並且其他容器和主機系統保持適當的隔離。透過遵循這些原則，可以構建一個更加安全的容器環境，即使面對最熟練的攻擊者也能保持韌性。

主機掛載與容器安全：深層風險剖析

在探索Kubernetes環境的安全盲點時，主機掛載（host mounts）經常被忽視，卻可能成為攻擊者的突破口。這些看似無害的設定選項，實際上可能為攻擊者提供進入系統的機會。讓我們探討這些潛在威脅點。

主機掛載的安全風險

Kubernetes的hostPath卷型別允許將主機上的檔案系統路徑掛載到容器中。這在某些應用場景中很有用，例如將/var/log掛載到容器中，使主機的日誌程式能夠收集容器的系統日誌事件。然而，這種便利性背後隱藏著嚴重的安全風險。

apiVersion: v1
kind: Pod
metadata:
  name: log-collector
spec:
  containers:
  - name: logger
    image: logger-image
    volumeMounts:
    - mountPath: /var/log
      name: host-logs
      readOnly: true  # 重要的安全限制
  volumes:
  - name: host-logs
    hostPath:
      path: /var/log
      type: Directory

上面的範例展示了一個將主機的/var/log目錄以唯讀方式掛載到容器中的Pod。注意readOnly: true這個關鍵設定 - 它限制了容器只能讀取而不能修改主機上的日誌檔案，這是降低風險的重要措施。沒有這個限制，容器可能會對主機檔案系統進行有害的修改。

主機掛載的常見用途與風險

主機掛載除了日誌收集外，還有這些常見用途：

  1. 為Pod中的資料儲存提供永續性
  2. 託管靜態資料、函式庫和快取
  3. 掛載主機上的通訊端（sockets）以允許容器與主機服務通訊

然而，使用主機磁碟或永久將儲存附加到節點，會在工作負載和底層節點之間建立緊密耦合。這使得工作負載必須在特定節點上重啟才能正常運作，大增加了擴充套件和彈性的難度。

更令人擔憂的是，主機掛載可能導致嚴重的安全漏洞：

# 攻擊者可能在容器內建立的惡意符號連結
ln -s /host-root-filesystem/ /app/data/symlink-attack

上述命令展示了攻擊者如何在容器內部建立符號連結，指向主機檔案系統。如果容器有權存取此符號連結指向的路徑，攻擊者可能繞過容器隔離，存取或修改主機檔案系統上的敏感檔案。這類別攻擊在CVE-2017-1002101中被發現，當時Kubernetes中處理符號連結的程式碼存在缺陷，允許容器內的攻擊者探索主機掛載的檔案系統。

通訊端掛載：容器逃逸的捷徑

將主機上的通訊端掛載到容器中是另一種常見但危險的做法。這允許容器內的客戶端對主機上的伺服器執行命令，但也可能成為容器逃逸的簡單途徑。

apiVersion: v1
kind: Pod
metadata:
  name: docker-socket-pod
spec:
  containers:
  - name: docker-control
    image: docker-client
    volumeMounts:
    - mountPath: /var/run/docker.sock
      name: docker-socket
  volumes:
  - name: docker-socket
    hostPath:
      path: /var/run/docker.sock

這個範例展示了將Docker通訊端掛載到容器中的危險設定。透過存取/var/run/docker.sock，容器內的程式可以控制主機上的Docker守護程式，啟動新的特權容器，甚至完全逃逸出容器環境。在實際生產環境中，這種設定應被視為嚴重的安全風險。

hostPath安全最佳實踐

使用hostPath時，我建議遵循這些安全實踐：

  1. 總是使用readOnly標誌限制對主機檔案系統的存取
  2. 在容器內使用非root使用者
  3. 如果容器內需要寫入許可權，在主機上正確設定案系統許可權
  4. 使用准入控制器限制hostPath存取特定目錄時，必須將這些volumeMount設為readOnly，否則新的符號連結可能被用於遍歷主機檔案系統

資料保護：業務的生命線

資料是業務的命脈，而狀態管理本身就很困難。攻擊者會尋找、竊取並可能加密鎖定系統中的任何資料。使用外部服務（如叢集外託管的物件儲存或資料函式庫）來持久化資料通常是最具彈性和可擴充套件的安全系統方式。

然而，對於高頻寬或低延遲的應用程式，這可能不可行。對於其他情況，雲提供商或內部服務整合可以移除工作負載與底層主機之間的聯絡，使系統擴充套件、升級和佈署變得更加容易。

管理服務與專用基礎設施

管理服務和專用基礎設施叢集是一種更容易理解的叢集安全抽象。這種方法將不同的工作負載分離到專用叢集中，減少了攻擊面和潛在的橫向移動。透過這種方式，即使一個叢集受到攻擊，其他叢集仍然可以保持安全。

惡意容器：隱藏的威脅

惡意容器是指受攻擊者控制的容器。這可能由以下幾種方式產生：

  1. 擁有Kubernetes存取許可權的攻擊者（透過kubelet或API伺服器）建立
  2. 嵌入自動化漏洞利用程式碼的容器映像（例如，使用dockerscan “特洛伊化"的映像，可以在合法容器中啟動反向shell）
  3. 佈署後被遠端攻擊者存取的容器

惡意容器映像的檔案系統攻擊

如果攻擊者能夠強制Kubernetes執行他們構建或破壞的容器，他們可能會嘗試攻擊協調器、容器執行時或客戶端（如kubectl）。

一種攻擊（CVE-2019-16884）涉及容器映像在AppArmor用於設定的目錄上定義VOLUME，本質上在容器執行時停用它：

mkdir -p rootfs/proc/self/{attr,fd}
touch rootfs/proc/self/{status,attr/exec}
touch rootfs/proc/self/fd/{4,5}

上述命令建立了一個特殊的目錄結構，當作為容器映像的一部分時，可以幹擾AppArmor的保護機制。這些目錄和檔案模擬了Linux proc檔案系統的關鍵部分，當作為VOLUME掛載時，可以覆寫或幹擾AppArmor的設定。雖然這本身可能不會直接導致完全的系統入侵，但它可以作為攻擊鏈中的一環，透過停用一層防禦來為後續攻擊鋪平道路。

另一個危險的容器映像是用於/proc/self/exe逃逸的CVE-2019-5736。這個漏洞需要一個具有惡意連結ENTRYPOINT的容器，所以不能在已經啟動的容器中執行。

這些攻擊表明，除非容器是由受信任的元件構建的，否則應該將其視為不受信任的，以防止進一步的未知攻擊。

kubectl cp漏洞

一系列kubectl cp CVE（CVE-2018-1002100，CVE-2019-11249）需要容器內部存在惡意的tar二進位檔案。漏洞源於kubectl信任從容器內部scp和tar程式接收的輸入，這些輸入可能被操縱以覆寫執行kubectl二進位檔案的機器上的檔案。

# 容器內部的惡意tar二進位檔案可能會執行：
tar cf - /path/to/sensitive/file --to-command="cat > /etc/malicious-file"

上面的命令展示瞭如何使用惡意的tar二進位檔案來利用kubectl cp的漏洞。當管理員使用kubectl cp從容器複製檔案時，容器內的惡意tar可以執行任意命令，寫入管理員機器上的敏感位置。這種攻擊特別危險，因為執行kubectl的使用者通常具有較高的系統許可權。

執行時安全：/proc/self/exe逃逸

CVE-2019-5736的危險在於，惡意容器程式可以覆寫主機上的runc二進位檔案。該runc二進位檔案由root擁有，但由於它也由主機上的root執行（大多數容器執行時需要一些root能力），所以在這次攻擊中，它可以從容器內部被覆寫。這是因為容器程式是runc的子程式，而這個漏洞利用了runc擁有的覆寫自身的許可權。

保護主機免受特權容器程式攻擊的最佳方法是從容器執行時中移除root許可權。runc和Podman都可以在無根模式下執行，這大降低了攻擊風險。

容器內的許可權降低

root使用者由於多年的核心開發（假設只有一個"root"使用者）而擁有許多特殊許可權。為了將遠端式碼執行（RCE）的影響限制在容器、Pod和主機範圍內，容器內的應用程式不應該以root身份執行，並且應該放棄其能力，與無法透過設定allowPrivilegeEscalation securityContext欄位為false（這會在容器程式上設定no_new_privs標誌）來取得許可權。

apiVersion: v1
kind: Pod
metadata:
  name: secure-pod
spec:
  containers:
  - name: app
    image: secure-app:latest
    securityContext:
      runAsNonRoot: true
      runAsUser: 1000
      allowPrivilegeEscalation: false
      capabilities:
        drop:
        - ALL

這個Pod設定展示了多層安全措施：

  1. runAsNonRoot: true - 確保容器不能以root使用者執行
  2. runAsUser: 1000 - 明確指定使用UID 1000（非特權使用者）執行容器
  3. allowPrivilegeEscalation: false - 防止程式取得更多許可權
  4. capabilities: drop: - ALL - 移除所有Linux能力，大幅減少容器的攻擊面

這些安全上下文設定共同工作，大降低了容器被入侵後可能造成的損害範圍。即使攻擊者獲得了容器內的程式碼執行許可權，他們也將受到嚴格限制，難以逃逸到主機系統。

容器安全的深層思考

在處理容器安全時，我發現採取多層防禦策略最為有效。單一的安全機制（如AppArmor）可能會被繞過，但多層防禦可以大提高攻擊者的難度和成本。

從我的經驗來看，容器安全需要考慮這些關鍵方面：

  1. 最小許可權原則 - 容器應該只擁有完成其工作所需的最低許可權
  2. 不可變基礎設施 - 容器應該被視為不可變的，任何更改都應該透過重新構建和重新佈署來實作
  3. 深度防禦 - 實施多層安全控制，包括網路政策、RBAC、安全上下文等
  4. 監控與檢測 - 持續監控容器行為，以檢測異常活動

此外，定期進行安全掃描和滲透測試對識別潛在漏洞至關重要。在容器化環境中，安全不是一次性的工作，而是一個持續的過程。

容器技術的快速發展意味著新的漏洞和攻擊向量不斷出現。保持警覺並跟上最新的安全最佳實踐是保護容器化環境的關鍵。在設計容器化系統時，我始終將安全性視為首要考慮因素，而不是事後增加的功能。

在容器安全領域，預防勝於治療。投資於安全的容器構建流程、強化的基礎映像和嚴格的佈署策略，可以在攻擊發生之前預防許多潛在問題。同時，準備好應對安全事件的計劃同樣重要，因為即使是最安全的系統也可能存在尚未發現的漏洞。

容器安全是一個不斷發展的領域，需要持續學習和適應。透過理解本文討論的威脅模型和防禦策略，你已經邁出了保護容器化環境的重要一步。記住，安全不是目的地，而是一段持續的旅程。

Kubernetes安全工具與RBAC分析利器

在容器化環境中，正確管理許可權是安全的根本。隨著Kubernetes的普及，越來越多的組織面臨許可權管理的挑戰。為了改善IAM策略，記錄AWS API呼叫是一個有效的方法，這能幫助我們瞭解實際的許可權使用情況，從而精確調整許可權範圍。

許可權管理工具箱

在Kubernetes環境中，有幾款工具特別值得關注，它們能夠幫助我們更好地分析和管理RBAC許可權：

  1. Krane - Kubernetes RBAC分析利器，它能夠視覺化呈現許可權結構，幫助管理員快速識別過度授權或許可權衝突

  2. audit2rbac - 這個工具能夠根據稽核日誌自動生成RBAC策略，特別適合在遷移舊系統到Kubernetes時使用

  3. RBAC View - 提供直觀的RBAC關係視覺化，幫助理解複雜的許可權依賴關係

  4. rback - 輕量級RBAC分析工具，專注於安全性檢查和許可權最佳化

  5. Permission Manager - 提供Web介面管理Kubernetes許可權，降低了RBAC管理的門檻

這些工具各有所長，我在實際佈署中發現，組合使用能夠提供最全面的許可權管理方案。例如，使用audit2rbac生成初始策略，再透過RBAC View進行視覺化檢查，最後用Krane進行深度安全分析。

Kubernetes歷史重大CVE解析

瞭解歷史安全漏洞對於防範未來攻擊至關重要。以下是Kubernetes生態系統中一些具有重要意義的CVE，它們揭示了容器安全的關鍵弱點和演進方向。

容器掛載與檔案系統漏洞

CVE-2017-1002101：子路徑掛載處理不當

這個漏洞允許容器透過子路徑掛載存取卷之外的檔案，包括主機檔案系統。即使是非特權Pod也能繞過檔案權限制，這嚴重違反了容器隔離原則。

CVE-2017-1002102：Downward API主機檔案刪除

使用Secret、ConfigMap、projected或downwardAPI卷的容器可能觸發主機上任意檔案或目錄的刪除。這個漏洞展示了卷掛載機制的安全風險，特別是當容器能夠影響主機檔案系統時。

這兩個CVE都與卷掛載機制有關，它們揭示了Kubernetes早期版本中容器與主機檔案系統隔離的不完善。在容器安全設計中，即使容器獲得了某種存取許可權，也不應該能夠逾越其邊界存取或修改主機檔案系統。這些漏洞的修復推動了Kubernetes儲存子系統的安全強化。

API伺服器與代理漏洞

CVE-2018-1002105：API伺服器Websocket TLS通道錯誤處理

這是一個嚴重的漏洞，允許攻擊者透過精心建構的請求，利用kube-apiserver中代理升級請求的錯誤處理，建立到後端伺服器的連線。後續透過同一連線的任意請求會直接傳輸到後端，並且使用Kubernetes API伺服器的TLS憑證進行認證。

這個漏洞本質上是一個許可權提升問題，攻擊者可以繞過正常的認證流程，獲得API伺服器的許可權級別。在多租戶環境中，這意味著租戶可能取得到超出其預期許可權的存取權。修復這個問題需要重新設計API伺服器如何處理代理請求和錯誤情況，特別是在涉及長連線（如Websocket）時的安全邊界。

容器執行時漏洞

CVE-2019-16884：runc惡意映象AppArmor繞過

這個漏洞允許繞過AppArmor限制，因為libcontainer/rootfs_linux.go不正確地檢查掛載目標，惡意Docker映象可以掛載覆寫/proc目錄。

CVE-2019-5736：runc /proc/self/exe漏洞

這是一個嚴重的容器逃逸漏洞，允許攻擊者覆寫主機上的runc二進位檔案，從而獲得主機root存取許可權。攻擊者可以透過以下兩種方式利用：

  1. 建立一個使用攻擊者控制的映象的新容器
  2. 附加到攻擊者之前有寫入許可權的現有容器

這個漏洞與/proc/self/exe的檔案描述符處理不當有關。

這些執行時漏洞展示了容器技術的根本挑戰：如何在分享同一內核的情況下實作強隔離。runc作為容器執行時的核心元件，其安全性直接影響整個容器生態系統。特別是CVE-2019-5736，它揭示了Linux proc檔案系統與容器邊界互動時的微妙問題。修復這些問題推動了容器執行時安全設計的演進，包括更嚴格的檔案系統隔離和存取控制。

kubectl工具漏洞

CVE-2019-11249：kubectl cp scp反向寫入

當使用kubectl cp從容器複製檔案時，Kubernetes會在容器內執行tar建立一個歸檔，並透過網路將其複製到使用者機器上解壓。如果容器中的tar二進位檔案是惡意的，它可以執行任何程式碼並輸出意外的惡意結果。攻擊者可以利用這一點在呼叫kubectl cp時寫入使用者機器上的任何路徑，僅受本地使用者的系統權限制。

CVE-2018-1002100：原始kubectl cp漏洞

kubectl cp命令不安全地處理從容器回傳的tar資料，可能被利用來覆寫任意本地檔案。

CVE-2019-1002101：符號連結漏洞

類別似於CVE-2019-11249，但擴充套件為untar函式可以同時建立和跟隨符號連結，進一步擴大了攻擊面。

kubectl作為與Kubernetes叢集互動的主要工具，其安全性至關重要。這些漏洞揭示了在設計檔案傳輸功能時的安全挑戰，特別是當需要跨越容器邊界時。核心問題在於信任模型：kubectl cp功能隱含地信任容器內的tar程式，但在惡意容器場景下，這種信任可能被濫用。這些漏洞的修復推動了更嚴格的輸入驗證和許可權檢查，以及對符號連結和特殊檔案處理的安全強化。

許可權與RBAC漏洞

CVE-2019-11247：叢集RBAC處理不當

Kubernetes kube-apiserver錯誤地允許存取叢集範圍的自定義資源，如果請求以該資源是名稱空間範圍的方式發出。這種方式存取的資源授權使用名稱空間內的角色和角色繫結來強制執行，這意味著只有在一個名稱空間中存取資源的使用者可以建立、檢視、更新或刪除叢集範圍的資源（根據他們的名稱空間角色許可權）。

這個漏洞揭示了Kubernetes授權系統的複雜性，特別是在處理不同範圍（名稱空間範圍vs叢集範圍）的資源時。問題的核心是API伺服器在強制執行授權決策時沒有正確區分這些範圍，導致許可權升級。這個漏洞特別危險，因為它允許有限許可權的使用者可能影響整個叢集的設定。修復這個問題需要重新審視RBAC系統如何處理不同範圍的資源，並確保授權決策考慮到資源的正確範圍。

訊息洩露漏洞

CVE-2019-11248：kubelet /debug/pprof訊息洩露

除錯端點/debug/pprof透過未認證的kubelet healthz健康檢查端點連線埠暴露，可能洩露敏感訊息，如Kubelet內部記憶體地址和設定，或導致有限的拒絕服務。

CVE-2019-11250：側通道訊息洩露

Kubernetes client-go函式庫在詳細級別為7或更高時記錄請求頭。這可能透過日誌或命令輸出向未授權使用者洩露憑證。使用基本或承載令牌認證並在高詳細級別執行的Kubernetes元件（如kube-apiserver）會受到影響。

這些漏洞強調了在設計系統時需要考慮訊息洩露風險，特別是在除錯功能和日誌記錄方面。CVE-2019-11248顯示了為方便除錯而暴露的端點如何成為安全風險，而CVE-2019-11250則提醒我們日誌記錄也可能是敏感訊息洩露的途徑。這些問題的修復包括增強存取控制、隱藏敏感訊息，以及改進日誌記錄實踐，確保即使在高詳細級別下也不會洩露憑證。

網路相關漏洞

CVE-2020-8558：kube-proxy意外暴露本地服務

kube-proxy意外地使本地主機繫結的服務在網路上可用，這違反了只有本地程式應該能夠連線到本地主機服務的期望。

這個漏洞涉及網路隔離的基本原則：本地主機（127.0.0.1）繫結的服務應該只能被本地程式存取。當kube-proxy錯誤地允許從網路存取這些服務時，它打破了這個安全邊界，可能導致未授權存取本應受保護的服務。這個問題的修復需要重新評估kube-proxy如何處理網路流量路由，並確保本地主機服務的隔離性得到維護。

核心與特權提升漏洞

CVE-2020-14386：本地網路介面整數溢位

在"loopback”（或localhost）網路介面上的原始資料包可能導致整數溢位。在未打補丁的核心上，可以透過設定 sysctl -w kernel.unprivileged_userns_clone=0 或拒絕 CAP_NET_RAW 來防止利用。

CVE-2021-22555：Linux Netfilter本地特權提升漏洞

在處理setsockopt IPT_SO_SET_REPLACE（或IP6T_SO_SET_REPLACE）時，本地使用者可能透過使用者名稱空間利用記憶體損壞取得特權或導致DoS。使用CONFIG_USER_NS和CONFIG_NET_NS編譯的核心允許非特權使用者提升特權。

CVE-2021-31440：Linux核心eBPF驗證器邊界計算錯誤

透過繞過驗證器，這可能利用內核的越界存取進行逃逸，原始概念驗證將UID和GID設定為0，並獲得CAP_SYS_MODULE以載入容器外的任意核心。

這些漏洞涉及Linux核心本身，它們對容器安全的影響特別深遠，因為容器分享主機核心。特別值得注意的是，這些漏洞允許特權提升，這在容器環境中尤其危險，因為它可能導致容器逃逸。這些案例強調了核心安全對容器整體安全的重要性，以及為什麼保持核心更新和限制容器能力（如CAP_NET_RAW）是關鍵的安全實踐。

符號連結與主機存取漏洞

CVE-2021-25741：符號連結交換可能允許主機檔案系統存取

使用者可能夠建立具有子路徑卷掛載的容器，以存取卷外的檔案和目錄，包括主機檔案系統上的檔案和目錄。

這個漏洞與早期的CVE-2017-1002101類別似，再次強調了卷掛載機制中的安全挑戰。符號連結是一個特別棘手的問題，因為它們可以建立檔案系統路徑的重定向。在容器環境中，如果不小心處理，符號連結可能允許容器存取超出其預期邊界的檔案。這個漏洞的修復需要更嚴格地驗證和處理符號連結，特別是在涉及子路徑掛載時。

安全最佳實踐與防護策略

瞭解了這些歷史漏洞後，我們可以總結出一些關鍵的Kubernetes安全最佳實踐：

  1. 保持系統更新：及時應用安全補丁，特別是針對容器執行時和Kubernetes元件

  2. 限制容器能力：遵循最小許可權原則，移除不必要的Linux能力，特別是CAP_NET_RAW等高風險能力

  3. 實施強大的RBAC策略：使用前面提到的RBAC分析工具，確保許可權最小化，定期審查和更新

  4. 保護卷掛載：謹慎處理子路徑掛載，避免符號連結相關漏洞

  5. 網路隔離：實施網路政策，限制Pod間通訊，保護本地主機服務

  6. 監控與稽核：啟用全面的稽核日誌，使用IDS/IPS系統檢測異常行為

  7. 安全容器映像檔：使用最小化基礎映象，實施映象掃描，避免使用未知來源的映象

  8. 強化kubelet設定：停用或保護除錯端點，限制kubelet的暴露面

在實際操作中，我發現結合使用這些策略能夠顯著提高Kubernetes環境的安全性。特別是，使用RBAC分析工具來定期審查許可權，結合容器執行時安全解決方案，可以構建多層防禦體系，即使面對零日漏洞也能提供一定程度的保護。

深入理解攻擊面與防禦策略

在分析這些CVE時，值得注意的是攻擊面的演變模式。早期的Kubernetes漏洞主要集中在基本的隔離機制上，如檔案系統隔離和容器邊界。隨著這些基本問題被解決，攻擊者轉向更複雜的攻擊向量，如RBAC繞過、API伺服器代理問題和客戶端工具漏洞。

這種演變表明，Kubernetes安全是一個不斷發展的領域，需要全面的安全策略。單純依賴於補丁和更新是不夠的，我們需要：

  1. 深度防禦：實施多層安全控制，包括網路政策、RBAC、Pod安全策略、執行時保護等

  2. 持續監控：佈署行為分析和異常檢測系統，識別可能的攻擊嘗試

  3. 假設突破：設計系統時假設某些控制可能會被突破，確保有額外的保護層

  4. 安全文化：培養DevSecOps文化，將安全考慮整合到開發和營運流程中

在處理多租戶Kubernetes環境時，這些考慮尤為重要。租戶之間的強隔離需要結合名稱空間隔離、網路政策、資源配額和適當的RBAC設計。

玄貓

玄貓

技術愛好者，專注於分享程式開發、雲端技術與 AI 應用的心得體會。