Kubernetes 安全性最佳實務：從建置到執行階段的強化

什麼是 Kubernetes 安全性？

Kubernetes 安全性是指你在建置、部署與執行階段套用的一組控制措施，用來保護叢集、其執行的工作負載，以及為其提供內容的管線。若沒有這些控制措施，一個未經驗證的請求就可能接管你的整個叢集。這正是 IngressNightmare，也就是 2025 年 3 月揭露於 ingress-nginx 中、嚴重性達 9.8 的漏洞；而該控制器運行於超過 40% 的 Kubernetes 叢集中。

其 admission webhook 位於 pod 網路上且沒有任何驗證，而 ingress-nginx 預設會讀取叢集中的每個 Secret。只要能連上該網路，就能掌控整個叢集。這不需要利用鏈，也不需要竊取密碼：只要寬鬆的預設設定照其被設定的方式運作即可。

Kubernetes 內建設定與正式環境叢集實際需求之間的這道落差，正是強化所要彌補的。Kubernetes 安全性最佳實務，就是你逐階段彌補這道落差的方法，從你建置的映像檔到你執行的工作負載皆然。由於編排會將你的工作負載、Secrets 與東西向流量集中於單一控制平面中，一個設定錯誤就可能讓你執行的每項服務全面暴露，這也是為什麼這項工作必須由你負責，而不是交給平台。

為什麼 Kubernetes 安全性很重要？

Kubernetes 不會自行強化。這份 CISA/NSA Kubernetes Hardening Guidance每個新叢集上都記錄了三個值得注意的預設值：已啟用匿名 API 伺服器登入、Secrets 以未加密形式儲存在 etcd 中，以及稽核記錄已關閉。共同責任模型將四項控制交由您負責：角色型存取控制 (RBAC)、網路政策、Secrets 加密，以及執行階段控制。雲端供應商不會替您設定它們，發行版本也不會。由於這些控制存在於您的組態中，且會隨時間產生漂移，團隊越來越常以持續方式驗證它們，使用Kubernetes 安全態勢管理，而不是手動稽核。

若攻擊者能接觸到未經驗證的 API server，就能讀取 etcd 中的每個 Secret、在任何節點上排程 pod，並在命名空間之間移動，同時稽核記錄仍毫無動靜，因此你收到的第一個訊號可能就是入侵本身。一個暴露的端點，幾分鐘內就會變成整個叢集的存取權，這與 IngressNightmare 採用的是相同模式。

風險會隨著採用率而擴大。Cloud Native Computing Foundation (CNCF) 年度雲端原生調查 指出 82% 的容器使用者現在已在正式環境中執行 Kubernetes，高於 2023 年的 66%。當叢集位於面向客戶的服務、受監管資料與稽核義務的路徑上時，任何一項遺漏的控制措施都會演變成資料外洩暴露、稽核失敗，以及需要由你的團隊負責回應的通報事件。只有在你知道叢集的哪些部分承擔這些風險後，了解風險的重要性才有意義。

Kubernetes 叢集的核心元件

你無法強化尚未盤點的項目。每個元件都帶有特定的安全暴露，而了解這些暴露會告訴你控制措施必須套用在哪裡。

控制平面元件：

• API server: 你執行的每個 kubectl 指令、每個 admission webhook，以及每個 service account token 請求，都會經過 API server。此處若遭未授權存取，就代表整個叢集遭到完全控制。
• etcd: 儲存你所依賴的所有叢集狀態、設定與 Secrets。對 etcd 的讀取權限，在功能上等同於你整個叢集的 root 權限。
• Scheduler and controller manager: 遭入侵的排程器可將工作負載放置到特定節點上，以利用本機資源。對控制器的操弄可在不被察覺的情況下變更部署、複本數量與資源指派。

工作節點元件：

• kubelet: 每個節點上的代理程式，負責執行 pod 規格。若你讓 kubelet API 暴露在外，攻擊者就能直接在節點上建立容器或執行命令。
• kube-proxy: 管理服務路由的網路規則。設定錯誤的 proxy 規則可能讓你的內部服務暴露給外部流量。
• Container runtime: 在主機上執行容器。存在弱點的 runtime 會讓其支援的每個容器以及主機本身暴露於風險中，正如 NIST SP 800-190 所指出。

Pods、容器與網路：

• Pods 會共用網路命名空間，因此 pod 中遭入侵的容器可在沒有網路控制的情況下存取同一 pod 中的其他容器。若沒有 NetworkPolicy 物件，不同命名空間中的 pods 預設可自由通訊。 
• 容器映像檔與 infrastructure-as-code (IaC) 範本會從外部登錄來源進入你的叢集，而一個被污染並拉取到正式環境的映像檔，會傳播到排程該映像檔的每個節點。將每個元件對應到其暴露面，能精確告訴你本指南中的強化控制措施應套用在哪裡。

Kubernetes 安全性如何在從建置到執行階段的生命週期中運作

你是透過持續性的工作流程來保護 Kubernetes，而不是靠一次性的檢查。每個階段都會強制執行不同類別的控制措施，而一個階段的輸出會成為下一個階段的輸入。以下是每個步驟中會發生的事。

1. 建置階段: 你會掃描容器映像檔中的已知弱點、依據政策驗證 IaC 範本、以密碼學方式簽署映像檔，並產生 software bill of materials (SBOM)。這些預防性控制措施會在來源端阻止問題，在任何成品被排程之前就先行攔截。
2. 部署與設定：當你提交工作負載時，admission controllers 會在排程前依據政策進行評估。 RBAC 決定誰可以建立、修改或讀取資源，而網路政策則定義哪些 Pod 可以通訊。您在建置時簽署的映像，只有在准入控制實際檢查簽章時，才會在此受到保護。
3. 控制平面與節點組態： 您會設定 API server、etcd、kubelet 和節點作業系統，以減少暴露面。驗證、授權與加密會設定其他每個階段所依賴的信任邊界，因此薄弱的控制平面會削弱下游的一切。
4. 執行階段：監控工具會監看執行中工作負載的行為異常、組態漂移與已知攻擊模式，而 seccomp 與 AppArmor 設定檔則限制您的容器可進行哪些系統呼叫。執行階段也是您補捉建置與部署所遺漏缺口的地方。

當執行階段的發現回饋到您的建置階段，成為更新後的映像、更新後的 IaC 與更新後的准入政策時，您就完成了閉環。只有在每一次交接都穩固無誤時，這個生命週期才會發揮作用。以下說明一次交接失敗的代價。

Kubernetes 叢集遭入侵的影響

當您的叢集遭到入侵時，後果遠不只影響單一工作負載。

• 橫向移動與爆炸半徑： 您的叢集執行數十到數千個共享網路連線能力的 Pod。當 RBAC 權限過大且缺少網路政策時，取得其中一個 Pod 存取權的攻擊者就能跨命名空間與節點進行橫向移動。
• 機密外洩： etcd 儲存您的 API 金鑰、資料庫認證、TLS 憑證與服務權杖。由於 Secrets 預設未加密，具備 etcd 讀取權限的攻擊者可以擷取您叢集中的所有認證。
• 供應鏈擴散： 透過持續整合與持續交付 (CI/CD) 管線部署的受污染容器映像，會到達每個排程該映像的節點。在執行數百個複本的叢集中，單一遭入侵的映像可在數分鐘內於您的整個基礎架構中執行惡意程式碼。
• 工作負載與資料遭入侵： 您的正式環境資料庫、面向客戶的應用程式與內部服務並行執行。單一工作負載中的一次入侵，可能暴露敏感資料、中斷服務可用性，或建立持續性存取以供未來攻擊使用。
• 合規與法規風險暴露： 如果您的叢集處理付款資料、健康紀錄或政府工作負載，則會受到 PCI DSS、HIPAA、FedRAMP 與 SOC 2 要求的規範。若組態錯誤的叢集未通過稽核，可能導致營運停擺與財務罰款。

強化可降低任何單一入侵的爆炸半徑，縮短 事件回應時程，並產出您的合規計畫所需的稽核證據。要在實務上做到這一點，比聽起來更困難，原因在於 Kubernetes 的執行方式本身。

保護 Kubernetes 的挑戰

Kubernetes 安全性 在營運上相當困難，即使對您最有經驗的團隊成員也是如此。此平台的短暫性、宣告式組態模型與分散式架構，造成了靜態安全工具原本並非為處理這些問題而設計的摩擦。

• 短暫且持續變動的工作負載： Pod 會持續被建立、銷毀與重新排程。您在上午 9 點取得的叢集態勢快照，到了上午 9 點 5 分可能已無法反映其狀態。
• 對執行中容器的可視性缺口： 容器共用主機核心，但會隔離其程序、檔案系統與網路堆疊。標準的主機型監控工具通常缺乏足夠的情境脈絡，無法區分正常的容器行為與惡意活動。
• 組態複雜性與漂移： 正式環境叢集涉及數百個 YAML 資訊清單、RBAC 綁定與准入規則。Git 中宣告的內容與叢集中實際執行的內容之間若出現漂移，就會引入未受追蹤的風險暴露。
• 多叢集與多雲蔓延： 如果您在 Amazon Web Services (AWS)、Azure、Google Cloud Platform (GCP) 與地端環境中執行叢集，您就必須在不同的受管服務之間強制執行一致的政策，而每項服務都有其各自的共同責任邊界。
• 工具零散分裂： 映像掃描、RBAC 管理、網路政策強制執行、執行階段監控與合規報告，通常需要彼此分離且沒有共用資料模型的工具。警示關聯分析的責任落在您身上。
• 技能與組織摩擦： 這類專業技能相當稀缺，而 2025 年 CNCF 調查發現，雲端原生採用的首要障礙首次是組織層面而非技術層面：內部溝通、團隊動態與領導層一致性。控制措施之所以未被套用，是因為沒有人負責。

這些限制形塑了您的工具選擇與招募優先順序，也說明了為何相同的錯誤會在各個叢集中反覆出現。

常見的 Kubernetes 安全錯誤

特定的操作人員反模式會造成攻擊者可利用的風險暴露。請在您的叢集中識別並消除以下每一項：

• 執行特權或 root 容器。 特權容器會繞過所有 Linux 核心隔離。以 root 身分執行且設定 allowPrivilegeEscalation: true 的容器可以逃逸到主機。
• 授與 cluster-admin 或萬用字元 RBAC。萬用字元權限 (resources: ["*"], verbs: ["*"]) 會自動延伸至尚不存在的 API 資源。Kubernetes 文件將此模式標示為「請勿使用」。
• 保留預設允許的網路設定。若沒有 NetworkPolicy 物件，您不同命名空間中的 Pod 可自由通訊。
• 以明文資訊清單儲存 Secrets。 將憑證提交到 Git 或以環境變數傳遞，會使其暴露於當機傾印、日誌和 shell 歷程記錄中。
• 略過映像與 IaC 掃描。 部署未經掃描的映像，會讓弱點在未受檢查的情況下進入正式環境。
• 將強化視為一次性的關卡。 在啟動時完成強化的叢集，會隨著團隊新增工作負載並修改組態而逐漸偏移。若沒有持續性強制執行，安全態勢就會惡化。
• 忽略節點與控制平面組態。 保留匿名 API 伺服器登入為啟用狀態、略過 etcd 加密，以及省略稽核記錄，都是需要您明確修正的預設狀態。

上述每一項都可透過以下做法修正。請將它們視為在將更多工作負載擴展到叢集之前，應先消除的暴露面檢查清單。

Kubernetes 安全性最佳實務

這些 Kubernetes 安全性最佳實務構成了 Kubernetes 叢集強化的作業核心，並依照上述介紹的相同四個生命週期階段進行組織。請依序執行，因為每個階段都以前一個階段已成立為前提。

保護建置階段

1. 在映像進入登錄庫之前掃描弱點。將 容器映像掃描整合到您的 CI 管線中，讓含有弱點的映像永遠不會成為可部署的成品。
2. 使用最小化或 distroless 基底映像。 Distroless 映像僅包含您的應用程式及其執行階段相依性，不含 shell、套件管理員或不必要的二進位檔。將映像固定為明確的版本後綴 (e.g., gcr.io/distroless/static-debian13)，且絕不要使用 latest tag。
3. 簽署並驗證映像。 在 CI 中使用 Cosign 或 Notary 簽署映像。設定准入控制器，在部署時拒絕未簽署或未驗證的映像。
4. 掃描 IaC 與 Kubernetes 資訊清單。 在 Terraform、Helm charts 與原始 YAML 進入叢集之前，先依安全性政策進行驗證。
5. 產生 SBOM 以為每個映像建立來源證明，並支援部署後的弱點追蹤。
6. 讓秘密資料遠離映像。 絕不要將憑證、API 金鑰或憑證檔烘焙進容器映像或 Dockerfiles 中。

這些建置階段控制可在任何內容執行之前，將含有弱點且未簽署的成品阻擋在管線之外。即使映像通過這些控制，只有在叢集正確准入時才算安全，而這正是部署時組態接手的地方。

強化叢集組態與部署

這些 Kubernetes RBAC 最佳實務與網路控制，會將部署時政策轉化為可強制執行的防護欄。

1. 套用最小權限 RBAC。 建立具明確動詞與資源名稱、以命名空間為範圍的 Roles。移除萬用字元授權。將 cluster-admin 限制為緊急破窗用途。對不需要 API 存取的服務帳戶設定 automountServiceAccountToken: false。

2. 強制執行預設拒絕的網路政策。 套用 default-deny-all Netwenforce 模式搭配 restrictedorkPolicy，於啟動時將輸入與輸出雙向政策套用至每個命名空間。依每個工作負載新增明確的允許規則，包括 UDP 連接埠 53 的 DNS 輸出例外。

3. 強制執行 Restricted Pod Security Standard。 在 enforce 模式下，對正式環境命名空間使用 restricted level 的 Pod Security Admission。這會封鎖特權容器、要求 runAsNonRoot、強制使用 seccomp 設定檔，並限制磁碟區類型。

4. 使用 OPA Gatekeeper 或 Kyverno 新增准入控制。 強制執行 readOnlyRootFilesystem: true, allowPrivilegeEscalation: false、映像檔登錄來源允許清單，以及 capability drop-ALL 原則。先使用 dryrun 模式稽核現有工作負載，再切換為 deny。

5. 在外部儲存區中管理 Secrets，並對 etcd 啟用靜態加密。 使用金鑰管理服務 (KMS) v2 提供者進行信封加密，並透過 Secrets Store CSI Driver 將 Secrets 以磁碟區方式掛載；其使用 tmpfs，因此機密資料不會寫入節點磁碟。避免將 Secrets 作為環境變數傳遞。

6. 設定資源限制。為每個容器定義 CPU 和記憶體 requests 與 limits，以防止資源耗盡。

在部署時原則已強制執行後，您的工作負載會在最小權限與預設拒絕的網路環境下執行。這些防護機制所依賴的信任基礎，仍位於控制平面及其下方的節點，因此接下來請強化這些部分。

保護控制平面與工作節點

控制平面是單一弱設定會影響其他所有部分的唯一位置。請設定以下各項，然後依排程驗證，而不是只在初始啟動時檢查一次。

當控制平面已鎖定且節點已完成修補後，基礎便穩固了。即時工作負載仍可能偏離其宣告狀態，或從內部遭受攻擊，而執行階段控制正是用來偵測這些情況的機制。

執行階段安全與威脅偵測

強大的 Kubernetes runtime security 能捕捉靜態控制無法發現的問題。

1. 監控執行階段行為。 部署容器原生的執行階段安全工具，以監看異常的系統呼叫、非預期的程序執行、網路連線與檔案修改。NIST SP 800-190 指出，傳統的入侵防護系統 (IPS) 與網頁應用程式防火牆 (WAF) 工具無法為容器提供適當的保護。
2. 偵測組態漂移。 將執行中的工作負載與其在 Git 中宣告的狀態進行比對。標記已偏離其原始映像或組態的容器。
3. 套用 seccomp 與 AppArmor 或 SELinux 設定檔。 使用 RuntimeDefault seccomp 設定檔作為最低標準。先在部分節點上部署自訂設定檔，驗證後再擴展至整個叢集。
4. 執行唯讀根檔案系統並移除不必要的能力。 設定 readOnlyRootFilesystem: true 與 capabilities: drop: [ALL] 於每個正式環境容器上。
5. 強制執行 runAsNonRoot。 要求在 Pod 安全性內容中設定 runAsNonRoot: true。在建置階段將映像建構為以非 root 使用者執行，而非僅依賴部署階段的覆寫設定。
6. 啟用自主回應與持續稽核記錄。 將執行階段警示與稽核記錄建立關聯，以重建攻擊時間軸。將發現結果回饋至建置階段政策，以形成閉環。

這四個階段共同產生持續強化的叢集。產業基準描述了每個階段中「正確設定」應有的樣貌，而您應該依據這些基準衡量您的叢集。

Kubernetes 安全標準與合規

業界認可的基準將上述實務具體化，並提供您的 Kubernetes 合規計畫所需的稽核證據。

如今 Kubernetes 已成為預設的正式環境平台，合規框架愈來愈將 Kubernetes 專屬控制項視為獨立的稽核領域，而非一般基礎架構安全的子集。 

平台專屬基準，例如 CIS GKE Benchmark 與 CIS OpenShift Benchmark，會以受管服務專屬控制項擴充一般基準。了解標準只是基準線。更困難的問題是 Kubernetes 安全接下來將走向何方。

Kubernetes 安全的未來趨勢

您今天部署的控制項立足於不斷變動的基礎之上，而三大趨勢正在重塑團隊採用 Kubernetes 安全最佳實務的方式。

1. AI 工作負載正在移動攻擊面。 隨著叢集成為 AI 與機器學習工作負載的預設承載環境，GPU 排程、模型成品與大型訓練資料集都成為新的目標。保護資料與模型供應鏈正逐漸成為叢集強化的一部分，而非獨立議題。
2. 軟體供應鏈完整性成為強制要求。SBOM 產生、已簽署成品與來源證明，正從可選的成熟度指標轉變為受監管產業與政府採購中的基準期望。
3. 自主執行階段防禦取代人工分流處置。 叢集活動的數量與速度已超出人工審查能力。能夠區分正常與異常工作負載活動，並且無需等待分析師即可回應的行為式 AI，正從差異化能力轉變為預設配置。

每個趨勢都指向相同方向：在生命週期更早階段導入更多自動化，並在執行階段實現更高自主性，而這正是平台工具發揮價值之處。

使用 SentinelOne 強化 Kubernetes 安全性

本指南涵蓋的原生 Kubernetes 控制項，包括 RBAC、NetworkPolicy、Pod Security Standards、etcd 加密與稽核記錄，構成了叢集強化的基礎。SentinelOne 在此之上新增了態勢管理、供應鏈掃描、K8s 准入控制，以及執行階段威脅偵測，且每一項都對應到本指南所指出的弱點。

Singularity Cloud Security在 Kubernetes 叢集實際執行之前先進行掃描。建置階段掃描可直接整合至 CI/CD 管線、版本控制系統與容器登錄庫。它會檢查已知漏洞，以及超過 750 種暴露的機密資訊。同一項掃描也涵蓋 infrastructure-as-code 範本，包括 Terraform、Helm、CloudFormation 與 Kubernetes YAML，以便及早發現政策違規。Kubernetes Admission Controller 作為 API 伺服器上的最後一道把關機制，在映像部署前封鎖未經授權或已知惡意的映像。

Kubernetes Security Posture Management (KSPM) 可彌補整個叢集中的可視性缺口。它會在叢集、節點、命名空間和部署之間建立統一的資產清單，然後揭露權限過於寬鬆的存取與高風險組態。接著，Offensive Security Engine™ 會模擬真實世界的攻擊，並透過 Verified Exploit Paths™ 確認攻擊者實際上可利用哪些錯誤組態。安全團隊會優先處理可被利用的項目，而不是對每一項發現進行分類處置。相同的規則引擎也為 Admission Controller 提供支援，因此從安全態勢到部署，政策都能維持一致。

在執行階段，Singularity Cloud Workload Security基於 extended Berkeley Packet Filter (eBPF) 可在機器速度下偵測異常行為。自動化回應會終止惡意程序並隔離受感染檔案，無需等待分析師。Graph Explorer 可視覺化 Kubernetes 攻擊面中的關聯，因此團隊能精確看見哪些項目已暴露。當執行階段偵測標記惡意映像檔時，該發現會自動回饋至 Admission Controller。接著，該映像檔將在未來所有部署中遭到封鎖，將一次偵測轉化為持續有效的政策。Purple AI 帶來自然語言 威脅狩獵 與事件摘要整合至單一資料湖中的雲端工作負載遙測資料，讓分析師能以自然語言查詢，而不必在多個工具之間切換。

查看您的叢集在正式環境中的暴露位置。 申請 SentinelOne 示範，逐步了解您自身環境中的 Kubernetes 態勢管理與執行階段威脅偵測。

Take A Tour

AI-powered cloud workload protection (CWPP) for servers, VMs, and containers, that detects and stops runtime threats in real time.

重點整理

Kubernetes 採用寬鬆的預設設定，將叢集安全掌握權交到您手中。本指南中的 Kubernetes 安全最佳實務涵蓋四個階段：建置時的映像掃描與簽署、部署時的 RBAC 與 NetworkPolicy、控制平面的 etcd 加密與稽核記錄，以及執行階段的行為監控。 

讓您的設定符合 CIS Benchmark 與 CISA/NSA 指引，消除上述已識別的常見錯誤，並透過將執行階段發現回饋至建置階段政策來完成閉環。做到這一點，您就不必再猜測。您可以在任何一天指出任何命名空間，並說明哪些措施已被強制執行、哪些發生了漂移，以及您如何處理。

Cloud Security Demo

Discover how AI-powered cloud security can protect your organization in a one-on-one demo with a SentinelOne product expert.

Get a Demo