Kubernetes 安全強化：Pod、網路及控制平面深度防禦

Kubernetes 作為容器協調的事實標準，其安全性也越來越受到重視。本文將探討如何強化 K8s 環境的安全性，涵蓋 Pod 安全策略、網路隔離與強化、資源管理以及控制平面防禦等關鍵導向。這些策略並非單獨存在，而是相互關聯，構成一個多層次的防禦體系，有效降低潛在風險。

在微服務架構下，Pod 安全是 K8s 安全的根本。除了善用 Pod Security Admission 和 Pod Security Policies，限制 Pod 的許可權，避免以 root 身份執行容器，更建議搭配 Security Context 和 AppArmor 等機制，強化容器的執行環境。網路層面的防護同樣重要，NetworkPolicy 能精細化控制 Pod 間的流量，結合 Service 與 Ingress 的設定，建立更嚴謹的網路存取控制。此外，資源管理也是不可忽視的一環，透過 LimitRange 和 ResourceQuota，限制 Pod 和名稱空間的資源使用，避免資源濫用和搶佔，確保服務穩定執行。最後，控制平面的安全更是重中之重，除了 RBAC 和 TLS 加密外，還需保護 etcd 資料函式庫和 kubeconfig 檔案，並強化 API Server 的存取控制。

Kubernetes 安全強化：玄貓的實戰經驗分享

身為一個在容器化技術領域打滾多年的老手，玄貓深刻體會到 Kubernetes (K8s) 在現代應用程式佈署中扮演的關鍵角色。然而，K8s 的複雜性也帶來了許多安全挑戰。許多企業因為 K8s 組態不當而遭受攻擊，這讓我不得不分享一些 K8s 強化的實戰經驗，希望能幫助大家建立更安全的 K8s 環境。

為何 K8s 安全如此重要？

K8s 是一個開源的容器協調系統，能自動化佈署、擴充套件和管理容器化應用程式。它將應用程式拆解為微服務，提高了靈活性和安全性，但也引入了新的複雜性。

想像一下，一個 K8s 叢集就像一個繁忙的城市，每個微服務都是一個獨立的部門。如果沒有完善的安全措施，駭客可以輕易地攻入任何一個部門，進而影響整個城市的運作。

K8s 安全強化建議

以下是玄貓根據多年經驗整理出的一些 K8s 安全強化建議：

1. Pod 安全強化

• 以非 root 使用者執行容器： 避免以 root 許可權執行容器，降低容器逃逸的風險。
• 使用不可變檔案系統： 將容器的檔案系統設為唯讀，防止惡意程式修改。
• 掃描容器映像檔： 定期掃描容器映像檔，找出潛在的漏洞和錯誤組態。
• 強制執行最低安全標準： 使用技術控制來強制執行最低安全標準，例如：
  • 禁止 privileged 容器。
  • 停用 hostPID、hostIPC、hostNetwork、allowedHostPath 等容易被利用的容器功能。
  • 拒絕以 root 使用者執行或允許提升到 root 許可權的容器。
  • 使用 SELinux、AppArmor 和 seccomp 等安全服務來強化應用程式。

2. 網路隔離與強化

• 使用防火牆和 RBAC 鎖定控制平面節點： 限制對控制平面節點的存取，並使用 RBAC 進行細粒度的許可權控制。
• 限制對 etcd 伺服器的存取： etcd 儲存了 K8s 叢集的所有狀態，必須嚴格限制對其的存取。
• 組態控制平面元件使用 TLS 憑證進行加密通訊： 確保控制平面元件之間的通訊經過加密，防止中間人攻擊。
• 加密 etcd 儲存的資料： 使用強加密方法加密 etcd 儲存的資料，防止資料洩漏。
• 設定網路策略以隔離資源： 使用網路策略來隔離不同名稱空間中的 Pod 和服務。
• 建立明確的拒絕網路策略： 建立一個明確的拒絕網路策略，防止未經授權的網路流量。
• 將憑證和敏感資訊加密儲存在 Kubernetes Secrets 中： 不要將憑證和敏感資訊儲存在設定檔中，而是使用 Kubernetes Secrets 進行加密儲存。

3. 身份驗證與授權

• 停用匿名登入： 預設情況下，K8s 允許匿名登入，必須停用此功能。
• 使用強使用者身份驗證： 使用強使用者身份驗證機制，例如多因素驗證。
• 建立具有唯一角色的 RBAC 策略： 為使用者、管理員、開發人員、服務帳戶和基礎架構團隊建立具有唯一角色的 RBAC 策略。

4. 稽核日誌記錄與威脅偵測

• 啟用稽核日誌記錄： 預設情況下，K8s 停用稽核日誌記錄，必須啟用此功能。
• 持久化日誌： 將日誌持久化儲存，確保在節點、Pod 或容器發生故障時仍然可用。
• 組態整個環境的日誌記錄： 組態整個環境的日誌記錄，包括 K8s API 稽核事件日誌、叢集指標日誌、應用程式日誌、Pod seccomp 日誌、儲存函式庫稽核日誌等。
• 彙總叢集外部的日誌： 將日誌彙總到叢集外部，方便集中管理和分析。
• 實作日誌監控和警示系統： 根據組織的叢集量身定製日誌監控和警示系統。

5. 升級與應用程式安全實務

• 立即套用安全修補程式和更新： 定期檢查並立即套用安全修補程式和更新。
• 執行定期漏洞掃描和滲透測試： 定期執行漏洞掃描和滲透測試，找出潛在的安全風險。
• 解除安裝並刪除環境中未使用的元件： 移除環境中未使用的元件，減少攻擊面。

玄貓的額外提醒

除了以上建議，玄貓還想提醒大家：

• 容器供應鏈安全： 確保容器映像檔來自可信任的來源，並定期掃描映像檔，防止惡意程式碼進入叢集。
• 服務網格： 考慮使用服務網格來整合日誌記錄和網路安全，提高叢集的整體安全性。

Kubernetes 安全強化：從 Pod 到 Container Image 的深度防禦

在雲原生時代，Kubernetes (K8s) 已成為容器化應用程式佈署的根本。然而，如同任何強大的工具，K8s 的安全性也需要嚴格把關。玄貓在過去參與多個大型 K8s 專案中，見證過不少因為組態疏忽導致的安全事件。因此，這篇文章將探討 K8s 環境中 Pod 和 Container Image 的安全強化策略，協助你開發更堅固的雲原生防線。

重新審視 Kubernetes 的威脅模型

在深入技術細節之前，讓玄貓先帶大家瞭解 K8s 環境中潛在的威脅來源：

• 惡意使用者： 擁有 K8s 叢集存取許可權的內部或外部人員，可能濫用許可權進行惡意操作。
• Container 應用程式漏洞： Container 內的應用程式若存在漏洞，可能被駭客利用，進而影響整個叢集。
• 雲端服務供應商 (CSP)： 雖然 CSP 通常具備嚴格的安全控制，但若其基礎設施被攻破，也可能危及 K8s 環境。

開發堅固的 Pod 防線：從 Rootless 到 Immutable Filesystem

Pod 是 K8s 中最小的佈署單元，也是駭客入侵的常見起點。強化 Pod 的安全性至關重要。

告別 Root 許可權：Non-Root Container 的實踐

預設情況下，許多 Container 服務以 Root 使用者身份執行，這大幅增加了 Container 被攻破後的風險。玄貓強烈建議採用 Non-Root Container，限制 Container 內的應用程式以非 Root 許可權執行。

有兩種方式可以實作 Non-Root Container：

1. 在 Dockerfile 中設定： 在建構 Container Image 時，就指定以非 Root 使用者執行應用程式。附錄 A 提供了一個範例 Dockerfile。
2. 使用 SecurityContext:runAsUser： 在 K8s 的 Pod 佈署設定中，透過 SecurityContext:runAsUser 強制以非零使用者執行 Container。

玄貓建議在建構 Container Image 時就整合 Non-Root 執行，這樣可以確保應用程式在沒有 Root 許可權的情況下也能正常運作。

Rootless Container Engine：更進一步的安全防護

Rootless Container Engine 是一種更先進的技術，它允許 Container Engine 在非特權環境中執行。從 Container 應用程式的角度來看，它仍然以 Root 使用者身份執行，但實際上已被重新對應到 Host 上的 Engine 使用者環境。

雖然 Rootless Container Engine 提供了額外的安全層，但目前許多 Rootless Container Engine 仍處於實驗階段，不建議在生產環境中使用。玄貓建議密切關注這項技術的發展，並在供應商發布與 K8s 相容的穩定版本後再採用。

Immutable Filesystem：鎖定 Container 的檔案系統

預設情況下，Container 擁有幾乎不受限制的執行許可權。駭客若成功入侵 Container，可以建立檔案、下載指令碼、修改應用程式。為了防止這些後續的惡意行為，玄貓建議鎖定 Container 的檔案系統，使其成為唯讀 (Read-Only) 狀態。

當然，這可能會影響到需要寫入許可權的合法應用程式。為瞭解決這個問題，K8s 管理員可以為需要寫入許可權的特定目錄掛載額外的 Read/Write 檔案系統。附錄 B 提供了一個範例佈署範本。

建構安全的 Container Image：從 Trusted Repository 到 Image Scanning

Container Image 的安全性直接影響到 K8s 環境的整體安全。以下是一些建構安全 Container Image 的關鍵步驟：

• 使用 Trusted Repository： 限制開發者只能使用受信任的 Repository，避免引入惡意或有漏洞的 Image。
• 實施 Image Scanning： 在 Container Build 的整個流程中，掃描 Image 以識別過時的 Library、已知的漏洞、以及不安全的設定 (例如不安全的 Port 或許可權)。
• 整合 Admission Controller： 使用 K8s 的 Admission Controller，在 Image 佈署到叢集之前進行掃描。若 Image 不符合組織的安全策略，則阻止佈署。

Admission Controller：K8s 的安全守門員

Admission Controller 是 K8s 的原生功能，可以在物件持久化之前攔截和處理對 K8s API 的請求。透過實作自訂或專有的 Webhook，可以在 Image 佈署到叢集之前掃描任何 Image。

玄貓認為，Admission Controller 是 K8s 安全強化中不可或缺的一環。

Kubernetes 安全強化：玄貓的實戰經驗分享

在容器化應用日益普及的今天，Kubernetes (K8s) 已成為佈署和管理容器化工作負載的標準。然而，隨著 K8s 的廣泛應用，其安全性也日益受到關注。身為一個在 K8s 領域打滾多年的老手，玄貓今天要跟大家分享一些 K8s 安全強化的實戰經驗，希望能幫助大家提升 K8s 環境的安全性。

Pod 安全管制：從策略到實踐

確保 Pod 的安全性是 K8s 安全的首要任務。K8s 提供了兩種主要的機制來強制執行 Pod 的安全需求：Pod Security Admission 和 Pod Security Policies (PSPs)。

Pod Security Admission：新一代安全防護

Pod Security Admission 是 K8s 1.23 版本中預設啟用的 Beta 功能。它根據將 Pod 分類別為 privileged、baseline 和 restricted 三個層級，提供了一種比 PSPs 更直接的實作方式。

• Privileged（特權）：此層級的 Pod 具有最高的許可權，允許執行幾乎所有的操作。
• Baseline（基準）：此層級的 Pod 遵循最小許可權原則，僅允許執行必要的操作。
• Restricted（受限）：此層級的 Pod 受到最嚴格的限制，旨在防止潛在的安全風險。

玄貓建議大家盡早採用 Pod Security Admission，因為它不僅易於使用，而與能夠有效地提升 K8s 環境的安全性。

Pod Security Policies (PSPs)：過渡時期的選擇

PSPs 是一種已被棄用的功能，但對於仍在過渡到 Pod Security Admission 的使用者來說，仍然可以透過強化 PSPs 來提升安全性。

額外的安全防護：第三方 Admission Controller

除了 K8s 原生的解決方案外，還有許多第三方解決方案可以提供更細粒度的策略控制。這些解決方案通常以 K8s Admission Controller 的形式實作，可以根據實際需求選擇適合的產品。

保護 Pod Service Account Tokens：避免許可權濫用

預設情況下，K8s 會在建立 Pod 時自動佈建一個 Service Account，並在 Pod 執行時將該帳戶的 Secret Token 掛載到 Pod 內部。然而，許多容器化應用程式並不需要直接存取 Service Account。

如果應用程式遭到入侵，駭客可能會利用 Pod 中的帳戶 Token 進一步入侵叢集。因此，當應用程式不需要直接存取 Service Account 時，K8s 管理員應確保 Pod 規格停用 Secret Token 的掛載。這可以透過在 Pod 的 YAML 規格中使用 "automountServiceAccountToken: false" 指令來完成。

apiVersion: v1
kind: Pod
metadata:
  name: my-pod
spec:
  automountServiceAccountToken: false
  containers:
  - name: my-container
    image: my-image

內容解密：

• apiVersion: v1：指定 Kubernetes API 的版本。
• kind: Pod：指定要建立的資源型別為 Pod。
• metadata.name: my-pod：Pod 的名稱。
• spec.automountServiceAccountToken: false：設定為 false，表示停用自動掛載 Service Account Token。
• spec.containers：定義 Pod 中包含的容器。
• spec.containers[0].name: my-container：容器的名稱。
• spec.containers[0].image: my-image：容器使用的映象。

在某些情況下，容器化應用程式可能會使用佈建的 Service Account Tokens 來驗證外部服務，例如雲端平台。在這些情況下，停用帳戶 Token 可能不可行。玄貓建議叢集管理員應確保實作 RBAC 來限制 Pod 在叢集內的許可權。

強化容器環境：多重防禦策略

除了上述措施外，還可以透過以下方式強化容器環境：

• Hypervisor-backed Containerization（根據 Hypervisor 的容器化）：Hypervisor 依靠硬體來強制執行虛擬化邊界，而不是作業系統。Hypervisor 隔離比傳統容器隔離更安全。
• Kernel-based Solutions（根據核心的解決方案）：seccomp 工具可以用來限制容器的系統呼叫能力，從而降低核心的攻擊面。
• Application Sandboxes（應用程式沙箱）：某些容器引擎解決方案提供在容器化應用程式和主機核心之間新增隔離層的選項。此隔離邊界強制應用程式在虛擬沙箱中運作，從而保護主機作業系統免受惡意或破壞性操作的影響。

網路隔離與強化：開發安全的網路環境

叢集網路是 K8s 的核心概念。容器、Pod、服務和外部服務之間的通訊必須納入考量。預設情況下，K8s 資源不會被隔離，並且如果叢集遭到入侵，則不會阻止橫向移動或許可權提升。資源隔離和加密可能是限制駭客在叢集內移動和許可權提升的有效方法。

Namespaces：資源分割的利器

K8s Namespaces 是一種在同一叢集中，在多個個人、團隊或應用程式之間分割叢集資源的方法。預設情況下，Namespaces 不會自動隔離。但是，Namespaces 會為範圍分配標籤，可用於透過 RBAC 和網路策略指定授權規則。

除了限制按 Namespace 存取資源的策略外，資源策略還可以限制儲存和計算資源，以便更好地控制 Namespace 層級的 Pod。

K8s 預設有三個 Namespaces，它們無法被刪除：

• kube-system (適用於 K8s 元件)
• kube-public (適用於公用資源)
• default (適用於使用者資源)

使用者 Pod 不應放置在 kube-system 或 kube-public 中，因為這些 Namespaces 保留給叢集服務使用。不同 Namespaces 中的 Pod 和服務仍然可以相互通訊，除非強制執行額外的隔離。

Network Policies：精細化的流量控制

每個 Pod 都有自己的叢集專用 IP 位址，並且在連線埠分配、命名、服務探索和負載平衡方面，可以像虛擬機器 (VM) 或實體主機一樣對待。K8s 可以將 Pod 轉移到其他節點，並在已終止的 Deployment 中重新建立 Pod。發生這種情況時，Pod IP 位址可能會變更，這表示應用程式不應依賴靜態 Pod IP。

K8s Service 用於解決 IP 位址變更的問題。Service 是一種將唯一 IP 位址指派給使用 Pod 組態中的標籤選取的一組邏輯 Pod 的抽象方法。該位址與 Service 的生命週期相關聯，並且在 Service 存活期間不會變更。與 Service 的通訊會自動在屬於 Service 成員的 Pod 之間進行負載平衡。

可以使用 NodePorts 或 LoadBalancers 在外部公開服務，也可以在內部公開服務。若要在外部公開服務，請設定服務以使用 TLS 憑證來加密流量。設定 TLS 後，K8s 支援兩種將服務公開到網際網路的方式：NodePorts 和 LoadBalancers。

將 type: NodePort 新增至服務規格檔案，會指派一個隨機連線埠，以使用叢集的公用 IP 位址公開到網際網路。如果需要，也可以手動指派 NodePort。將型別變更為 LoadBalancer 可以與外部負載平衡器結合使用。可以使用網路策略控制 Ingress 和 Egress 流量。雖然無法依名稱在網路策略中選取服務，但可以使用組態中使用的標籤來選取 Pod，以便為服務選取 Pod。

如何利用 Kubernetes 網路策略強化安全性：玄貓的實戰經驗

在 Kubernetes 環境中，網路策略扮演著至關重要的角色，它能有效控制 Pod、名稱空間以及外部 IP 位址之間的流量。預設情況下，Kubernetes 叢集內的 Pod 和名稱空間沒有任何網路策略的限制，這意味著它們可以自由地接收和傳送流量，這也同時帶來了潛在的安全風險。

網路策略的核心作用

網路策略的主要作用是隔離 Pod。一旦將網路策略應用於特定的 Pod 或名稱空間，所有未經明確授權的連線都會被拒絕。這就像是在你的應用程式周圍建立一道防火牆，只允許經過授權的流量透過。

實施網路策略的先決條件

要成功建立和應用網路策略，你需要一個支援 NetworkPolicy API 的容器網路介面（CNI）外掛程式。常見的 CNI 外掛程式包括 Calico、Cilium 和 Weave Net。選擇合適的 CNI 外掛程式是實施有效網路策略的基礎。

如何選擇 Pod？podSelector 和 namespaceSelector 的妙用

在定義網路策略時，你需要明確指定策略應用於哪些 Pod。這可以透過 podSelector 和 namespaceSelector 選項來實作。podSelector 允許你根據 Pod 的標籤選擇 Pod，而 namespaceSelector 則允許你選擇整個名稱空間。

玄貓提示： 靈活運用這兩個選項，可以實作精細化的網路流量控制。

預設拒絕策略：強化安全的第一步

為了確保 Kubernetes 叢集的安全性，建議管理員建立一個預設策略，選取所有 Pod 並拒絕所有進入和外出的流量。這就像是在預設情況下關閉所有連線，然後逐步開放需要的連線。

玄貓經驗分享： 在為某金融科技公司設計 Kubernetes 網路安全策略時，我發現預設拒絕策略能有效降低潛在的攻擊面。

使用 ipBlock 控制外部 IP 位址

網路策略還允許你使用 ipBlock 來控制外部 IP 位址的流量。這對於限制對特定外部服務的存取非常有用。

注意事項： 不同的 CNI 外掛程式、雲端供應商或服務實作可能會影響 NetworkPolicy 處理的順序以及叢集內位址的重寫。

網路分段：構建多層防禦體系

網路策略可以與防火牆和其他外部工具結合使用，以建立網路分段。將網路劃分為獨立的子網路或安全區域，有助於將導向公眾的應用程式與敏感的內部資源隔離。

玄貓觀察： 網路分段的主要優勢之一是限制攻擊面和橫向移動的機會。

網路策略檢查清單

• 使用支援 NetworkPolicy API 的 CNI 外掛程式
• 使用 podSelector 和/或 namespaceSelector 建立策略來選擇 Pod
• 使用預設策略拒絕所有進入和外出的流量，確保未選取的 Pod 被隔離到所有名稱空間（kube-system 除外）
• 使用 LimitRange 和 ResourceQuota 策略來限制名稱空間或 Pod 層級的資源

Kubernetes 資源管理：玄貓談 LimitRange、ResourceQuota 與 PID 限制

在 Kubernetes 中，資源管理是確保應用程式穩定執行和叢集資源合理分配的關鍵。LimitRange、ResourceQuota 和程式 ID 限制（PID Limits）是三種重要的資源管理策略，它們可以有效地限制名稱空間、節點或 Pod 的資源使用。

LimitRange：精細控制 Pod 和容器資源

LimitRange 策略用於約束特定名稱空間內每個 Pod 或容器的個別資源，例如強制執行最大計算和儲存資源。每個名稱空間只能建立一個 LimitRange 約束。

玄貓建議： 透過 LimitRange，你可以確保每個 Pod 都獲得足夠的資源，同時防止單個 Pod 消耗過多的資源。

ResourceQuota：總體控制名稱空間資源使用

與 LimitRange 策略不同，ResourceQuota 限制的是整個名稱空間的總體資源使用，例如限制總 CPU 和記憶體使用量。

玄貓經驗分享： 在多租戶 Kubernetes 環境中，ResourceQuota 對於防止一個租戶消耗過多資源，影響其他租戶的應用程式至關重要。

PID 限制：防止節點資源耗盡

程式 ID（PID）是節點上的基本資源，如果沒有適當的限制，可能會被耗盡，從而導致主機守護行程（如 kubelet 和 kube-proxy）無法執行。管理員可以使用節點 PID 限制來為系統使用和 Kubernetes 系統守護行程保留指定數量的 PID。Pod PID 限制用於限制每個 Pod 上執行的行程數。

玄貓提示： 雖然可以使用驅逐策略來終止行為異常並消耗異常資源的 Pod，但驅逐策略是定期計算和執行的，並不能強制執行限制。

Kubernetes 控制平面強化：玄貓的安全實踐

控制平面是 Kubernetes 的核心，它允許使用者檢視容器、排程新的 Pod、讀取密碼以及在叢集中執行命令。由於這些敏感功能，控制平面應該受到高度保護。除了 TLS 加密、RBAC 和強大的身份驗證方法等安全組態外，網路隔離也有助於防止未經授權的使用者存取控制平面。

保護 Kubernetes API 伺服器

Kubernetes API 伺服器在連線埠 6443 上執行，應該受到防火牆的保護，只接受預期的流量。Kubernetes API 伺服器不應暴露於網際網路或不受信任的網路。

玄貓建議： 應用網路策略到 kube-system 名稱空間，以限制網際網路對 kube-system 的存取。

控制平面連線埠和服務

下表列出了控制平面連線埠和服務：

強化控制平面的步驟

1. 設定 TLS 加密
2. 設定強大的身份驗證方法
3. 停用對網際網路和不必要或不受信任的網路的存取
4. 使用 RBAC 策略限制存取
5. 使用身份驗證和 RBAC 策略保護 etcd 資料函式庫
6. 保護 kubeconfig 檔案免受未經授權的修改

Etcd 安全：玄貓的資料保護策略

etcd 後端資料函式庫儲存狀態資訊和叢集密碼。它是控制平面的關鍵元件，獲得對 etcd 的寫入許可權可能會使網路攻擊者獲得對整個叢集的 root 存取許可權。etcd 伺服器應組態為僅信任分配給 API 伺服器的憑證。etcd 可以在單獨的控制平面節點上執行，允許防火牆限制僅對 API 伺服器的存取。

玄貓強調： etcd 後端資料函式庫是控制平面的關鍵元件，也是控制平面中最重要的安全保護物件。

Kubeconfig 檔案安全

kubeconfig 檔案包含有關叢集、使用者、名稱空間和身份驗證機制的敏感資訊。Kubectl 使用儲存在工作節點和控制平面本機的 $HOME/.kube 目錄中的組態檔案。網路攻擊者可以利用對此組態目錄的存取許可權來存取和修改組態或憑證，從而進一步入侵叢集。應保護組態檔案免受意外變更，並阻止未經身份驗證的非 root 使用者存取這些檔案。

工作節點分段

工作節點可以是虛擬或實體機器，具體取決於叢集的實作方式。由於節點執行微服務並託管叢集的 Web 應用程式，因此它們通常是漏洞利用的目標。如果節點遭到入侵，管理員應主動限制攻擊面，將工作節點與不需要與工作節點或 Kubernetes 服務通訊的其他網路區段分開。

在 Kubernetes 環境中，網路策略、資源管理和控制平面強化是確保叢集安全性的關鍵要素。透過實施這些策略，你可以有效地降低潛在的安全風險，並確保應用程式的穩定執行。