Kubernetes 安全強化實務

– 12 分鐘閱讀

在雲原生時代，Kubernetes (K8s) 已成為容器協調的標準，但其安全性也面臨諸多挑戰。從網路層級的防火牆設定到應用程式層級的 Secrets 管理，每個環節都至關重要。本文將探討如何強化 K8s 安全性，涵蓋網路、資料加密、存取控制、日誌管理等導向，並提供實務上的最佳建議。

Kubernetes 安全性並非單一層面的問題，它涉及多個層面，需要綜合考量。首先，網路層級的防護至關重要。利用防火牆策略，我們可以有效隔離 K8s 叢集的內外網路，限制外部對內部服務的直接存取，減少潛在的攻擊面。除了網路隔離，資料加密也是不可或缺的一環。所有 K8s 元件之間的通訊都應使用 TLS 1.2 或更高版本進行加密，保護資料在傳輸過程中的安全。

再來，Secrets 管理是保護敏感資訊的關鍵。K8s Secrets 提供了比環境變數或設定檔更安全的儲存機制，但仍需進一步強化。建議啟用資料靜態加密，或使用外部金鑰管理服務 (KMS) 加密 Secrets，並透過 RBAC 策略嚴格控管存取許可權，遵循最小許可權原則。此外，雲端 Metadata 服務也可能成為攻擊者的目標。應限制 Pod 對 Metadata 服務的存取，避免洩露雲端基礎設施資訊或短期憑證。

最後，RBAC 是 K8s 授權管理的核心。應避免使用 AlwaysAllow 等不安全的授權模式，並善用 Roles、ClusterRoles、RoleBindings 和 ClusterRoleBindings，精細化控制資源的存取許可權。同時，稽核日誌和威脅偵測也是安全管理的重要環節。建立全面的日誌記錄系統，監控關鍵事件，並定期分析日誌，及早發現異常活動，才能有效防範潛在威脅。

Kubernetes 強化：開發更安全的雲原生環境

在雲原生架構中，Kubernetes (K8s) 已成為容器化應用程式佈署的標準。然而，隨著 K8s 的普及，其安全性也日益受到關注。不安全的 K8s 組態可能導致嚴重的資料外洩和系統入侵。因此，強化 K8s 環境的安全性至關重要。

防火牆策略：隔離內外網路

在規劃 K8s 網路時，防火牆扮演著重要的角色。透過防火牆，我們可以將內部網路區隔成不同的網段，限制外部對內部服務的直接存取。

  • 情境設定：假設我們有一個 K8s 叢集，其中包含對外提供服務的 Worker Node，以及儲存敏感資料的資料函式庫。
  • 防火牆組態：
    • 在 Worker Node 前端設定防火牆，只允許必要的網路流量透過，例如 HTTP/HTTPS。
    • 將資料函式庫佈署在與 Worker Node 隔離的內部網段，僅允許特定服務存取。
  • 額外考量：
    • 審慎評估需要對外開放的服務，避免暴露不必要的攻擊面。
    • 定期檢查防火牆規則，確保其有效性。

玄貓建議：在設計防火牆規則時，應採用最小許可權原則，只允許必要的流量透過。

加密傳輸：保護資料安全

在 K8s 叢集中，所有元件之間的通訊都應使用 TLS 1.2 或 1.3 加密。這包括 Pod 之間的通訊、Node 與 Control Plane 之間的通訊等。

  • TLS 設定：
    • 在 K8s 安裝過程中或之後，使用 TLS bootstrapping 設定加密。
    • 確保所有 Node 都已正確分發憑證，以便安全通訊。
  • 憑證管理：
    • 定期輪換憑證，降低憑證洩漏的風險。
    • 使用自動化工具管理憑證，簡化操作流程。

玄貓觀點：加密傳輸是保護 K8s 資料安全的重要手段，應確保所有元件之間的通訊都經過加密。

Secrets 管理：保護敏感資訊

K8s Secrets 用於儲存敏感資訊，例如密碼、OAuth Token 和 SSH 金鑰。相較於將敏感資訊儲存在 YAML 檔案或環境變數中，Secrets 提供了更嚴格的存取控制。

  • 加密 Secrets：
    • 預設情況下，K8s 以未加密的 Base64 編碼字串儲存 Secrets。
    • 啟用資料靜態加密 (Data-at-Rest Encryption)，或使用外部金鑰管理服務 (KMS) 加密 Secrets。
  • 存取控制：
    • 使用 RBAC 策略限制對 Secrets 資源的存取。
    • 僅授權需要存取 Secrets 的使用者或服務帳戶。
  • 範例設定：
    • 修改 kube-apiserver 的 Manifest 檔案，加入 --encryption-provider-config 引數。
    apiVersion: v1
kind: Pod
metadata:
  name: kube-apiserver
spec:
  containers:
  - name: kube-apiserver
    command:
    - kube-apiserver
    - --encryption-provider-config=/etc/kubernetes/encryption-config.yaml
    • 建立 encryption-provider-config.yaml 檔案，指定加密提供者。
    apiVersion: apiserver.config.k8s.io/v1
kind: EncryptionConfiguration
resources:
- resources:
  - secrets
  providers:
  - aescbc:
      keys:
      - name: key1
        secret: <base64 encoded secret>
  - identity: {}
    • 執行以下指令，讀取並加密所有 Secrets。
    kubectl get secrets --all-namespaces -o json | kubectl replace -f -

玄貓提醒：KMS 提供者可以防止原始加密金鑰儲存在本機磁碟上，提高安全性。

保護雲端基礎設施

K8s 經常佈署在雲端環境的 VM 上。因此，我們需要仔細考慮 VM 的攻擊面。在許多情況下，執行在這些 VM 上的 Pod 可以存取敏感的雲端 Metadata 服務。這些 Metadata 服務可能提供攻擊者關於雲端基礎設施的資訊，甚至是雲端資源的短期憑證。

  • Metadata 服務：
    • 雲端 Metadata 服務通常位於非路由位址上。
    • 攻擊者可能濫用這些服務進行許可權提升。
  • 防護措施：
    • 使用網路策略或雲端組態策略，防止 Pod 存取雲端 Metadata 服務。
    • 遵循雲端供應商的，強化這些存取管道。

玄貓經驗：在為某金融科技公司設計 K8s 佈署時，我發現限制 Pod 對 Metadata 服務的存取，能有效降低安全風險。

身份驗證與授權

身份驗證和授權是限制對叢集資源存取的主要機制。如果叢集組態錯誤，攻擊者可以掃描已知的 K8s Port，並在未經身份驗證的情況下存取叢集的資料函式庫或發出 API 呼叫。

  • 使用者型別：
    • 服務帳戶 (Service Accounts)：代表 Pod 處理 API 請求。
    • 一般使用者帳戶 (Normal User Accounts)：用於人類使用者。
  • 身份驗證機制：
    • Kubernetes 支援多種使用者身份驗證機制，包括 X509 客戶端憑證、Bootstrap Token 和 OpenID Token。
    • 至少應實作一種使用者身份驗證方法。
  • 停用匿名請求：
    • 匿名請求 (Anonymous Requests) 是未經身份驗證的請求。
    • 停用匿名請求可以防止攻擊者在未經授權的情況下存取叢集資源。
    • 透過將 --anonymous-auth=false 選項傳遞給 API 伺服器來停用匿名請求。
  • RBAC
    • RBAC 是一種根據組織內個人角色的存取控制方法。
    • 使用 RBAC 可以限制使用者帳戶和服務帳戶的存取許可權。
    • 檢查 RBAC 是否已啟用：執行 kubectl api-version，確認是否列出 .rbac.authorization.k8s.io/v1。
    • 若未啟用 RBAC，使用 --authorization-mode 標籤啟動 API 伺服器：kube-apiserver --authorization-mode=RBAC。

玄貓建議：避免使用弱身份驗證方法，例如靜態密碼檔案，因為這可能允許攻擊者以合法使用者的身份進行身份驗證。

總而言之，強化 Kubernetes 安全性需要多方面的考量，從網路隔離、加密傳輸到身份驗證和授權，每個環節都至關重要。透過實施這些最佳實踐，我們可以開發更安全的雲原生環境，保護我們的應用程式和資料免受威脅。

RBAC 許可權管理：開發 Kubernetes 安全防線

在 Kubernetes 環境中，授權管理至關重要。若未正確組態，將可能導致未經授權的存取，進而危害整個叢集的安全。其中，RBAC（Role-Based Access Control，根據角色的存取控制）是 Kubernetes 內建的授權機制，能有效管理叢集資源的存取許可權。

避免 AlwaysAllow：授權模式的陷阱

若您在 Kubernetes 叢集中啟用 AlwaysAllow 等授權模式，將會繞過所有授權檢查，導致任何請求都能透過。這就好比大門永遠敞開，任何人都能自由進出，完全喪失了存取控制的能力。因此，務必停用這類別授權模式，確保 RBAC 正常運作。

Roles 與 ClusterRoles：許可權設定的雙雄

RBAC 提供了兩種設定許可權的方式：

  • Roles：針對特定名稱空間設定許可權。
  • ClusterRoles：針對所有叢集資源設定許可權，不受名稱空間限制。

這兩者都只能用於新增許可權，無法設定拒絕規則。若叢集已啟用 RBAC 與停用匿名存取，Kubernetes API 伺服器將會拒絕所有未明確允許的許可權。

RoleBindings 與 ClusterRoleBindings：連線角色與使用者

單有 Role 或 ClusterRole 僅定義了許可權，並未將其與使用者連結。RoleBindings 和 ClusterRoleBindings 的作用，就是將 Role 或 ClusterRole 與使用者、群組或服務帳戶繫結。

  • RoleBindings：在特定名稱空間中，將 Role 或 ClusterRole 的許可權授予使用者、群組或服務帳戶。
  • ClusterRoleBindings：跨所有叢集資源，將 ClusterRole 的許可權授予使用者、群組或服務帳戶。

ClusterRole 可與多個 RoleBinding 搭配使用，限制許可權範圍。例如，多個名稱空間中的使用者需要類別似的許可權時，可使用同一個 ClusterRole，再透過不同的 RoleBinding 將範圍限制在個別的名稱空間。

最小許可權原則：安全管理的根本

賦予使用者、群組和服務帳戶的許可權應遵循最小許可權原則，僅授予完成任務所需的最低許可權。使用者群組有助於簡化 Role 的管理。不同群組（如使用者、管理員、開發人員和基礎架構團隊）需要不同的資源存取許可權，不應具備編輯或檢視其他群組資源的許可權。使用者、使用者群組和服務帳戶應僅能與所需資源所在的特定名稱空間互動和檢視。

透過建立具有適當 API 請求動詞和所需資源的 RBAC Role 或 ClusterRole，可以限制對 Kubernetes API 的存取。市面上也有工具能協助稽核 RBAC 策略，列印出使用者、群組和服務帳戶及其相關的 Role 和 ClusterRole。

稽核日誌與威脅偵測：Kubernetes 環境的守護者

稽核日誌記錄了叢集中所有已歸屬的活動。有效的日誌解決方案和日誌審查對於確保服務按照預期運作和組態，以及確保系統安全至關重要。系統化的安全稽核要求對安全設定進行一致與徹底的檢查，以協助識別潛在的風險。Kubernetes 能夠捕捉稽核日誌，以追蹤已歸屬的叢集動作，並監控基本的 CPU 和記憶體使用量資訊；然而，它本身並未提供全功能的監控或警示服務。

全面的日誌記錄：掌握環境全貌

在 Kubernetes 中執行應用程式的系統管理員應為其環境建立有效的日誌記錄和監控系統。僅記錄 Kubernetes 事件不足以提供系統上所發生動作的完整畫面。應在環境的所有層級執行日誌記錄，包括主機、應用程式、容器、容器引擎、映像檔登入檔、API 伺服器和雲端（如適用）。捕捉這些日誌後，應將其匯總到單一服務，以便安全稽核員、網路防禦人員和事件回應人員能夠全面瞭解整個環境中所採取的動作。

在 Kubernetes 環境中，管理員應監控/記錄以下事件：

  • API 請求歷史
  • 效能指標
  • 佈署
  • 資源消耗
  • 作業系統呼叫
  • 協定、許可權變更
  • 網路流量
  • Pod 擴充套件
  • 磁碟區掛載動作
  • 映像檔和容器修改
  • 許可權變更
  • 排定的工作 (cronjob) 建立和修改

建立 Pod 基準線：識別異常活動

當管理員建立或更新 Pod 時，應捕捉網路通訊、回應時間、請求、資源消耗和任何其他相關指標的詳細日誌，以建立基準線。還應定期審查 RBAC 策略組態，並在組織的系統管理員發生人事變更時進行審查。這樣做可確儲存取控制始終符合本的根據角色的存取控制章節中概述的 RBAC 策略強化指導方針。

例行系統安全稽核應包括將目前日誌與正常活動的基準測量值進行比較，以識別任何已記錄指標和事件的重大變更。系統管理員應調查重大變更以確定根本原因。例如，資源消耗的顯著增加可能表示應用程式使用情況發生變化或安裝了惡意程式（例如加密貨幣挖礦程式）。

應對內部和外部流量日誌進行稽核，以確保已正確組態所有預期的連線安全限制，並且這些限制按預期工作。管理員還可以隨著系統的發展使用這些稽核來評估可能限制外部存取的位置。

將日誌串流到外部日誌記錄服務將有助於確保叢集外部的安全專業人員可以使用這些日誌，使他們能夠儘可能即時地識別異常情況。如果使用此方法，則應使用 TLS 1.2 或 1.3 在傳輸過程中加密日誌，以確保網路攻擊者無法在傳輸過程中存取日誌並取得有關環境的寶貴資訊。

總之，Kubernetes 的安全強化需要全面的方法，包括強大的 RBAC 策略和全面的日誌記錄和監控實務。透過實施這些措施，組織可以顯著降低其 Kubernetes 環境中未經授權存取和惡意活動的風險。

Kubernetes日誌安全強化：實戰

在 Kubernetes 環境中，日誌記錄不僅僅是除錯工具，更是安全監控和事件追蹤的關鍵。本文玄貓將探討如何強化 Kubernetes 的日誌設定，確保日誌的完整性、可用性與安全性，同時避免敏感資訊洩露。

保護外部日誌伺服器：追加寫入許可權的重要性

當使用外部日誌伺服器時，一個重要的安全措施是設定 Kubernetes 內的日誌轉發器，使其僅具有對外部儲存的追加寫入許可權。這能有效防止叢集內部對已儲存日誌的刪除或覆寫，確保日誌的不可篡改性。

Kubernetes原生稽核日誌：深入組態

kube-apiserver 作為 Kubernetes 控制平面的前端，處理所有對叢集的內部與外部請求。每個請求都會產生稽核事件，而 kube-apiserver 會根據稽核策略檔案中的規則記錄這些事件。

稽核策略的重要性

Kubernetes 預設不啟用稽核日誌功能。叢集管理員必須編寫 YAML 格式的稽核策略檔案，定義規則並指定稽核事件的記錄層級。有效的規則必須指定以下四個稽核層級之一：

  • none：不記錄事件。
  • Metadata：僅記錄事件的中繼資料。
  • Request：記錄事件的請求內容。
  • RequestResponse：記錄事件的請求與回應內容。

稽核層級的選擇

將所有事件記錄在 RequestResponse 層級能提供最大的資訊量，有助於事件回應。然而，這也可能導致敏感資訊（如 base64 編碼的 Secrets）被記錄在日誌中。玄貓建議將涉及 Secrets 的請求記錄層級降低至 Metadata，以避免洩露敏感資訊。

客製化稽核策略

在生產環境中，記錄所有事件在最高層級會產生大量的日誌。因此，稽核策略應根據組織的需求進行客製化，降低非關鍵事件的記錄層級。關鍵在於移除冗餘，同時確保能清晰地追蹤叢集中發生的事件。

範例：稽核策略

一個實用的範例是將 Secrets 的稽核層級設為 metadata，而將所有其他事件設為 RequestResponse 層級。

啟用稽核日誌

要啟用稽核日誌，需要設定 kube-apiserver 的設定檔，並使用適當的 flags 將稽核策略檔案傳遞給 kube-apiserver。

日誌後端設定：可組態的選項

kube-apiserver 提供了可組態的日誌記錄和 webhook 後端。日誌記錄後端將稽核事件寫入日誌檔案，而 webhook 後端則可將檔案傳送到外部 HTTP API。

  • --audit-log-path 和 --audit-log-maxage 是用於組態日誌記錄後端的 flags 範例。
  • log-path flag 是啟用日誌記錄的最低要求組態。
  • 日誌檔案的預設格式為 JSON，但可以根據需要進行更改。

Kubernetes 還提供了一個 webhook 後端選項，管理員可以透過提交 YAML 檔案到 kube-apiserver 來手動組態，以將日誌推播到外部後端。

工作節點與容器日誌：多種組態方式

在 Kubernetes 架構中，有多種組態日誌記錄的方式。預設方法是由每個節點上的 kubelet 負責管理日誌。kubelet 根據其策略（包括檔案長度、儲存持續時間和儲存容量）在本地儲存和輪換日誌檔案。

存取容器日誌

可以使用以下命令列印 Pod 中容器的日誌：

kubectl logs [-f] [-p] POD [-c CONTAINER]
  • -f flag 用於串流日誌。
  • -p flag 用於檢索先前容器例項的日誌。
  • -c flag 用於指定容器（如果 Pod 中有多個容器）。

遠端日誌解決方案

如果發生錯誤導致容器、Pod 或節點死亡，Kubernetes 的原生日誌解決方案無法儲儲存存在失敗物件中的日誌。因此，玄貓建議組態遠端日誌解決方案，以在節點發生故障時儲存日誌。

玄貓

玄貓

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