Kubernetes 十大安全問題

Kubernetes 作為事實上的容器編排平台，已改變組織部署、擴展及管理容器化應用程式的方式。雖然它提供強大的能力與靈活性，但其固有的複雜性與動態特性也帶來多項安全挑戰。由於 Kubernetes 叢集橫跨多個節點並承載多樣化的工作負載，維護安全性成為一項艱鉅的任務。

本文探討常見的 Kubernetes 安全 問題，並提供可採取行動的因應策略。

Kubernetes 安全性的必要性

隨著企業將其工作負載轉移至 Kubernetes，

Cloud Native Computing Foundation 於 2023 年的調查顯示，93% 的受訪者在過去一年中至少經歷過一次 Kubernetes 安全事件，其中 78% 對其安全態勢缺乏信心；另一份 Aqua Security 報告則發現，在正式環境中執行 Kubernetes 的組織中，高達 90% 在同一期間遭遇過安全事件。

近期備受矚目的事件凸顯了採取強健 Kubernetes 安全措施的關鍵需求。2018 年，Tesla 的 Kubernetes 主控台遭入侵，導致敏感資料外洩，且運算資源遭未經授權用於加密貨幣挖礦。較近期的案例是 2021 年，容器執行階段中的一項弱點 (CVE-2021-32760) 讓攻擊者得以逃逸容器隔離，並可能取得主機系統的 root 存取權限。

這些事件明確提醒我們，Kubernetes 安全並非可有可無，而是任何大規模執行容器化工作負載的組織都必須具備的基本要求。

近年來發現的一些值得注意的 Kubernetes 弱點包括：

• CVE-2018-1002105: Kubernetes API server 中的一項重大缺陷，允許未經授權的使用者提升權限，並在叢集中的任何 pod 上執行任意命令。
• CVE-2019-11246: `kubectl cp` 命令中的一項弱點，可能讓攻擊者將惡意檔案寫入使用者工作站上的任意路徑。
• CVE-2020-8554: 一項中間人弱點，影響 LoadBalancer 與 ExternalIPs 服務中的外部 IP 位址。
• CVE-2021-25741: 磁碟區清理程序中的一個錯誤，可能讓攻擊者存取先前已終止 pod 中的敏感資訊。

為何 Kubernetes 不安全？

Kubernetes 的多面向架構本質上會帶來各種弱點，例如：

• API Server 暴露: API server 是叢集控制平面的核心中樞，因此是主要攻擊目標。
• RBAC 設定錯誤: 定義不當的角色與權限可能導致未經授權的存取。
• 未受限制的網路政策: 缺乏網路分段會助長叢集內的橫向移動。
• 預設容器組態: 以 root 權限或預設設定執行的容器很容易遭到利用。

CNAPP Market Guide

Get key insights on the state of the CNAPP market in this Gartner Market Guide for Cloud-Native Application Protection Platforms.

Read Guide

Kubernetes 安全問題

Kubernetes 安全情勢持續演變，新的威脅也不斷出現。然而，下列問題代表 Kubernetes 管理員與安全團隊所面臨的一些最關鍵且持續存在的挑戰：

#1. 未經授權的存取與權限提升

未經授權存取 Kubernetes 資源，是當今叢集面臨的最關鍵安全風險之一。取得叢集存取權的攻擊者，可能執行惡意程式碼、竊取敏感資料，或中斷營運。

因應方式：

1. 實作強健的角色型存取控制 (RBAC) 政策：
   • 定義遵循最小權限原則的細粒度角色與叢集角色。
   • 使用命名空間區隔工作負載，並限制權限範圍。
   • 定期稽核與檢視 RBAC 政策，以確保其持續適當。
2. 啟用並設定 Kubernetes Pod Security Policies (PSPs) 或 Pod Security Standards (PSS)：
   • 對 pod 的建立與執行施加限制，例如防止特權容器或限制主機命名空間存取。
   • 使用 PSPs/PSS 在整個叢集中強制執行安全最佳實務。
   • 實作強健的驗證機制： 使用 OpenID Connect (OIDC) 或其他聯合身分識別提供者進行使用者驗證。
   • 對所有叢集存取強制執行多重要素驗證 (MFA)。
   • 定期輪替服務帳戶權杖，並限制其權限。
3. 保護 Kubernetes API server：
   • 啟用並設定 API server 准入控制器，例如 PodSecurityPolicy 與 NodeRestriction。
   • 對所有 API server 通訊使用 TLS，並驗證用戶端憑證。

#2. 不安全的 API 伺服器組態

Kubernetes API 伺服器是管理叢集資源的主要進入點。API 伺服器中的錯誤組態或弱點，可能對叢集安全造成嚴重後果。

如何處理：

1. 保護 API 伺服器端點：
   • 對所有 API 伺服器通訊使用強式 TLS 加密。
   • 實作 IP 白名單，以將存取限制於受信任的網路。
   • 考慮使用堡壘主機或 VPN，供遠端存取 API 伺服器。
2. 啟用並設定准入控制器：
   • 使用 AlwaysPullImages 准入控制器，以確保使用最新的映像版本。
   • 啟用 NodeRestriction 准入控制器，以限制 kubelet 權限。
   • 針對組織特定的安全性原則，實作自訂准入控制器。
3. 稽核記錄與監控：
   • 啟用並設定 Kubernetes 稽核記錄，以追蹤所有 API 伺服器請求。
   • 使用 Falco 或 Sysdig 等工具，偵測並警示可疑的 API 伺服器活動。
4. 定期弱點掃描：
   • 定期對 API 伺服器及相關元件執行弱點掃描。
   • 隨時掌握 Kubernetes 安全公告，並及時套用修補程式。

#3. 有弱點的容器映像

容器映像構成 Kubernetes 工作負載的基礎。使用過時或有弱點的映像，可能為叢集帶來重大安全風險。

如何處理：

1. 實作映像掃描：
   • 使用 Trivy、Clair 或 Anchore 等工具，掃描映像中的已知弱點。
   • 將映像掃描整合至您的 CI/CD 管線中，以防止部署有弱點的映像。
2. 強制執行映像簽署與驗證：
   • 實作受信任的映像登錄，並使用 Notary 等工具進行映像簽署。
   • 設定准入控制器，只允許來自受信任來源的已簽署映像。
3. 將映像攻擊面降至最低：
   • 使用 Alpine 或 distress images 等精簡基礎映像，以降低潛在攻擊面。
   • 從正式環境映像中移除不必要的套件與公用程式。
4. 讓映像保持最新：
   • 定期更新基礎映像與應用程式相依性。
   • 在有可用更新時，實作自動化流程以重新建置並重新部署映像。

#4. 網路原則錯誤組態

Kubernetes 的預設網路組態允許所有 Pod 彼此通訊，這可能在發生入侵時導致橫向移動。

如何處理：

1. 實作網路原則：
   • 使用 Kubernetes Network Policies 來定義並強制執行 Pod 對 Pod 通訊規則。
   • 採用「全部拒絕」的預設立場，並明確允許必要流量。
2. 分割網路流量：
   • 使用命名空間在邏輯上分隔工作負載，並在命名空間層級套用網路原則。
   • 實作網路微分段，以限制潛在入侵的影響範圍。
3. 加密 Pod 對 Pod 流量：
   • 使用 Istio 或 Linkerd 等服務網格，加密 Pod 之間的流量。
   • 對所有叢集內部通訊實作雙向 TLS (mTLS)。
4. 監控網路流量：
   • 使用 Cilium 或 Calico 等工具，提供進階網路可視性與原則強制執行。
   • 實作網路流量記錄與分析，以偵測異常流量模式。

#5. Secrets 管理

妥善管理 API 金鑰、密碼和憑證等敏感資訊，對於維護 Kubernetes 工作負載的安全性至關重要。

如何處理：

1. 使用 Kubernetes Secrets：
   • 將敏感資訊儲存在 Kubernetes Secrets 中，而不是將其硬式編碼於 pod 規格或 config maps 中。
   • 使用 AWS KMS 或 HashiCorp Vault 等加密提供者，對靜態 Secrets 進行加密。
2. 實作外部秘密管理：
   • 使用 External Secrets Operator 或 Sealed Secrets 等工具，與外部秘密管理系統整合。
   • 實作即時秘密佈建，以將敏感資訊的暴露降至最低。
3. 定期輪替秘密：
   • 對所有敏感憑證實作自動化秘密輪替。
   • 在可行情況下使用短生命週期的權杖和憑證，以將潛在遭入侵的影響降至最低。
4. 限制秘密存取：
   • 使用 RBAC 依據知悉必要原則限制對 Secrets 的存取。
   • 對所有 Secret 存取與修改實作稽核記錄。

#6. Etcd 資料存放區安全性

etcd 鍵值存放區是 Kubernetes 中所有叢集狀態的主要資料存放區。若 etcd 遭到入侵，攻擊者可能取得對整個叢集的完全控制權。

如何處理：

1. 對靜態 etcd 資料進行加密：
   • 使用 EncryptionConfiguration 資源為 etcd 啟用加密。
   • 使用高強度加密金鑰並定期輪替。
2. 保護 etcd 通訊安全：
   • 對所有 etcd 對等節點與用戶端通訊使用 TLS。
   • 為 etcd 存取實作用戶端憑證驗證。
3. 備份與災難復原：
   • 對 etcd 資料實作定期且加密的備份。
   • 測試並驗證 etcd 還原程序，以確保資料完整性。
4. 限制 etcd 存取：
   • 在具有限制存取的專用節點上執行 etcd。
   • 使用網路政策限制哪些元件可以與 etcd 通訊。

#7. 執行階段安全風險

容器執行階段安全性 對於防範利用執行中容器漏洞的攻擊至關重要。

如何處理：

1. 實作執行階段安全監控：
   • 使用 Falco 或 Sysdig 等工具來偵測並警示可疑的容器行為。
   • 實作行為基準分析，以識別異常的容器活動。
2. 啟用 SELinux 或 AppArmor：
   • 使用 SELinux 或 AppArmor 設定檔來限制容器能力與檔案系統存取。
   • 針對特定應用程式需求實作自訂安全設定檔。
3. 使用 seccomp 設定檔：
   • 實作 seccomp 設定檔，以限制容器可使用的系統呼叫。
   • 從預設拒絕設定檔開始，並逐步允許必要的系統呼叫。
4. 容器沙箱化：
   • 可考慮使用 gVisor 或 Kata Containers，以增強容器與主機系統之間的隔離。

#8. 記錄與監控缺口

全面的記錄與監控對於在 Kubernetes 環境中偵測及回應安全事件至關重要。

如何處理：

1. 集中式記錄：
   • 實作如 ELK stack 或 Splunk 的集中式記錄解決方案，以彙總所有叢集元件的記錄。
   • 使用 Fluentd 或 Logstash 等記錄轉送代理程式，從容器與節點收集記錄。
2. 實作強健的監控：
   • 使用 Prometheus 和 Grafana 監控叢集健康狀態與效能指標。
   • 實作自訂警示規則，以偵測潛在的安全性問題。
3. 安全資訊與事件管理 (SIEM)：
   • 將 Kubernetes 日誌與指標整合至SIEM solution，以進行進階威脅偵測與關聯分析。
   • 針對常見安全事件實作自動化事件回應手冊。
4. 持續合規性監控：
   • 使用 Kube-bench 或 Kube-hunter 等工具，持續評估叢集是否符合安全最佳實務。
   • 針對常見錯誤設定實作自動化修復。

#9. 供應鏈攻擊

軟體供應鏈，包括容器映像與相依性，可能成為將弱點引入 Kubernetes 環境的途徑。

如何因應：

1. 實作軟體物料清單 (SBOM)：
   • 為所有容器映像與應用程式相依性產生並維護 SBOM。
   • 使用 Syft 或 Tern 等工具，在建置流程期間自動產生 SBOM。
2. 保護 CI/CD 管線：
   • 為所有 CI/CD 系統實作強式存取控制與驗證。
   • 使用已簽署的提交與已驗證的建置，以確保已部署成品的完整性。
3. 弱點管理：
   • 對軟體供應鏈的所有元件實作持續性弱點掃描。
   • 使用 Dependabot 或 Snyk 等工具，自動更新具有已知弱點的相依性。
4. 安全的成品儲存：
   • 使用受信任且具存取控制的成品儲存庫來儲存容器映像與其他建置成品。
   • 實作映像簽署與驗證，以確保已部署成品的完整性。

#10. 過時元件與 CVEs

讓Kubernetes元件與相關工具保持最新，對於維持叢集的安全態勢至關重要。

如何因應：

1. 定期修補與更新：
   • 為所有 Kubernetes 元件實作定期修補排程，包括控制平面、工作節點與附加元件。
   • 使用 kube-bench 等工具識別過時元件與錯誤設定。
2. CVE 監控與管理：
   • 訂閱 Kubernetes 安全公告與相關 CVE 資訊來源。
   • 實作評估並排定影響叢集元件之 CVE 優先順序的流程。
3. 自動化更新測試：
   • 在將 Kubernetes 更新套用至正式環境之前，先於預備環境中實作自動化測試。
   • 使用金絲雀部署或藍綠更新，以將潛在問題的影響降至最低。
4. 版本偏差管理：
   • 了解 Kubernetes 元件之間受支援的版本偏差，並確保所有元件皆在受支援範圍內。
   • 規劃定期的主要版本升級，以跟上最新的安全功能與修補。

Kubernetes 安全最佳實務

除了處理特定安全性問題之外，實作一套全面性的安全最佳實務，對於維持強健的 Kubernetes 安全態勢也至關重要。以下是一些值得考慮的關鍵實務：

1. 映像掃描

在為應用程式建置映像時，可能會產生數個安全攻擊面，例如；使用來自不受信任登錄庫的程式碼，

攻擊者可能利用映像中的任何這些弱點逃逸容器、取得主機或 Kubernetes worker node 的存取權；若成功，他們即可存取在該主機上執行的所有其他容器。具備這種層級的控制後，他們將能夠讀取主機磁碟區中的資料、檔案系統，以及可能在該主機上執行的 Kubelet 組態，包括 Kubulet 的驗證權杖以及其用於與 Kubernetes API server 通訊的憑證。這將使攻擊者有機會進一步破壞叢集並提升權限。

因此，可使用 Sysdig、Synk、Trivy 等工具定期掃描容器映像中的弱點，這些工具具備會更新的弱點資料庫，並會根據那些已知弱點掃描您的映像。這可在推送至登錄庫之前，於您的 CI/CD 管線建置期間完成。

2. 以非 Root 使用者身分執行

只要可行，請將容器設定為以非 root 使用者身分執行。在建置映像時，建立專用的服務使用者，並以該使用者而非 root 使用者執行應用程式。這可限制容器遭入侵時的潛在影響。

# 建立群組與使用者

RUN groupadd -r myapp && useradd -g myapp myapp

# 設定擁有權與權限

RUN chown -R myapp:myapp / app

# 切換至使用者

USER myapp

MD node index.js

注意： 這可能會被 pod 本身中的潛在錯誤設定覆寫。

在 pod 規格中使用 securityContext 欄位，將 runAsUser 和 runAsGroup 設為非零值。此外，設定 allowPrivilegeEscalation: false 以防止容器內發生權限提升。

3. 使用者與 RBAC 權限

實作細粒度的 Role-Based Access Control (RBAC) 原則，以確保使用者與服務帳戶僅擁有執行其任務所需的權限。定期稽核 RBAC 原則並移除不必要的權限。使用如 rbac-lookup 或 `rakkess` 等工具來視覺化並分析 RBAC 設定。

4. 使用網路原則

依預設，叢集中的每個 pod 都可以彼此通訊，這表示如果攻擊者取得一個 pod 的存取權，他們就能存取任何其他應用程式 pod。但實際上，並非每個 pod 都需要與其他 pod 通訊，因此我們可以透過實作 Kubernetes Network Policies 來限制它們之間的通訊，以控制 pod 對 pod 及 pod 對外部的通訊。

採用「全部拒絕」的預設立場，並明確允許必要流量。使用如 Cilium 或 Calico 等工具，以進行進階網路原則強制執行與可視性管理。

以達到最大化

5. 加密通訊

Kubernetes 中 pod 之間的通訊未經加密，因此攻擊者可能以明文讀取所有通訊內容。對 API server 通訊、etcd 對等與用戶端流量，以及 kubelet 連線使用 TLS。實作如 Istio 或 Linkerd 等服務網格，以啟用 pod 對 pod 通訊的雙向 TLS (mTLS)。

6. 保護機密資料

對於認證資料、秘密權杖、私密金鑰等敏感資料，會儲存在 Kubernetes 的 secrets 資源中，但依預設僅以 base64 編碼未加密儲存，因此任何有權檢視 secrets 的人都可以直接解碼其內容

您可以使用原生解決方案 – Kubernetes Secrets 來儲存敏感資訊，並使用加密提供者對靜態資料進行加密。

考慮使用外部秘密管理解決方案，例如 HashiCorp Vault 或 AWS Secrets Manager，以增強安全性並集中管理跨多個叢集的 secrets。

7. 保護 Etcd 儲存體

對靜態 etcd 資料進行加密，並使用 TLS 保護 etcd 通訊。對 etcd 存取實作用戶端憑證驗證，並使用網路原則限制對 etcd 節點的存取。定期備份 etcd 資料並測試還原程序。

8. 自動化備份與還原

實作叢集狀態的自動化加密備份，包括 etcd 資料與持久性磁碟區。定期測試還原程序，以確保資料完整性並在災難發生時將停機時間降至最低。考慮使用如 Velero 等工具，以取得 Kubernetes 原生的備份與還原功能。

9. 設定安全性原則

使用如 Open Policy Agent (OPA) Gatekeeper 或 Kyverno 等工具實作並強制執行安全性原則。這些工具可讓您在整個叢集中定義並強制執行自訂原則，例如要求特定標籤、強制執行資源限制，或限制使用特權容器。

10. 災難復原

為您的 Kubernetes 叢集制定並定期測試完整的災難復原計畫。這應包括從各種故障情境中復原的程序，例如節點故障、控制平面中斷或資料毀損。對關鍵工作負載實作多區域或多叢集策略，以確保高可用性與韌性。

CNAPP Buyer’s Guide

Learn everything you need to know about finding the right Cloud-Native Application Protection Platform for your organization.

Read Guide

SentinelOne 的 Kubernetes 安全性

SentinelOne 是一個專注於端點安全、偵測與回應的網路安全平台。談到 Kubernetes 安全性時，SentinelOne 提供以原則為基礎的方法來保護 Kubernetes 上的環境。以下簡要概述 SentinelOne 的 Kubernetes 安全性原則：

主要功能：

• Kubernetes Security Posture Management：它可從叢集、節點與 pod 安全態勢的角度，提供 Kubernetes 環境的整體檢視。此平台甚至可識別錯誤設定區域、易受攻擊的映像檔與合規性問題。
• Policy-as-Code：透過 SentinelOne，您可以在 YAML/JSON 檔案中將安全性原則表達為程式碼，以提供版本控制與自動化，並確保該環境的一致性。
• Real-time Threat Detection：由 AI 驅動的行為分析引擎可即時偵測並回應威脅，包括容器逃逸、權限提升與橫向移動。
• Automated Response：此平台進一步整合透過自動化回應來遏制與修復威脅的功能，降低 MTTD 與 MTTR。
• Compliance and Governance：SentinelOne 提供可自訂的原則與報告，以維持對 PCI-DSS、HIPAA、GDPR 等多項標準的合規性。

以下是 SentinelOne 支援的幾類原則，以確保 Kubernetes 的安全性

• Network Policies: 這些有助於控制 Pod 與服務之間的流量，無論是傳入或傳出。
• Pod 安全性政策: 建立 Pod 層級的安全性設定、權限提升、磁碟區掛載和網路政策
• 叢集安全性政策: 在叢集上強制執行安全性設定，其中包括驗證、授權和准入控制
• 映像安全性政策: 掃描映像中的弱點，並依據安全性基準強制執行合規性

這些是 SentinelOne 強制執行政策的方式，包括

• Kubernetes 准入控制: 與 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 安全性不是一次性的工作，而是持續改善、監控與調適的過程。請隨時掌握 Kubernetes 生態系統中的最新安全性發展，定期評估叢集的安全態勢，並準備在新威脅與弱點出現時迅速回應。

See SentinelOne in Action

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

Get a Demo