2025年03月22日玄貓（BlackCat）

Kubernetes 佈署與安全防護機制解析

本文探討 Kubernetes 佈署與安全防護機制，比較 GKE、EKS 和 AKS 三大公有雲 Kubernetes 服務，並詳述 Kubernetes 的驗證、授權、准入控制及稽核等多層次安全防禦體系，涵蓋靜態令牌、ServiceAccount 令牌、X.509 使用者端憑證和 OIDC 令牌等驗證方法。

容器技術雲端技術

Kubernetes AKS GKE EKS 安全防護 RBAC

Kubernetes 已成為容器協調的事實標準，其佈署與安全防護至關重要。本文比較了 Google Kubernetes Engine (GKE)、Amazon Elastic Kubernetes Service (EKS) 和 Azure Kubernetes Service (AKS) 三大公有雲平台的 Kubernetes 服務，分析其自動更新、使用便捷性、擴充套件性、安全性以及價格等方面的差異，協助使用者選擇合適的平台。同時，本文也探討了 Kubernetes 的多層次安全防禦體系，包含驗證、授權、准入控制和稽核，並解析了靜態令牌檔案、ServiceAccount 令牌等驗證方法的運作原理及優缺點，為 Kubernetes 的安全佈署和管理提供實務參考。

在 Microsoft Azure 上使用 Azure Kubernetes Service（AKS）佈署 Kubernetes 叢集

自動更新功能比較

在公有雲端服務中，Kubernetes 叢集的自動更新功能是至關重要的。以下是三大公有雲端服務供應商的比較：

Google Kubernetes Engine（GKE）：控制平面和節點都支援自動更新。
Amazon Elastic Kubernetes Service（EKS）：控制平面的更新是按需進行的，而節點的更新則需要手動操作。
Azure Kubernetes Service（AKS）：控制平面和節點都支援自動更新。

使用便捷性與雲端服務整合

GKE：具有高度直觀的介面，但設定相對複雜。
EKS：設定較為複雜，需要較高的技術門檻。
AKS：提供高度直觀的介面，使用便捷性高，尤其是對於已經使用 Azure 服務的使用者。

擴充套件性與安全性

三大服務都具備良好的擴充套件性和安全性，能夠與各自的雲端生態系統緊密整合。

價格比較

GKE 和 AKS：控制平面免費，只需為工作節點付費。
EKS：控制平面和節點皆按小時計費。

多區域叢集支援與私有叢集支援

三大服務皆支援多區域叢集和私有叢集。

無伺服器計算選項

GKE：使用 Cloud Run for Anthos 提供無伺服器計算選項。
EKS：使用 Fargate for EKS 提供無伺服器計算選項。
AKS：使用 AKS 虛擬節點提供無伺服器計算選項。

重點觀察

GKE 在 Kubernetes 版本支援和自動更新方面領先。
AKS 被認為是最為使用者友好的服務，尤其是對於已經使用 Azure 服務的使用者。
EKS 對控制平面收費，而 GKE 和 AKS 只對工作節點收費。
三大服務都與各自的雲端生態系統有強大的整合能力。

章節重點

Microsoft Azure 的歷史與 AKS 的演變：瞭解 Azure 如何發展以及其容器服務的演進。
註冊 Azure 帳戶並組態 Azure CLI：完成註冊並安裝必要的工具以管理 AKS 叢集。
啟動 AKS 叢集並佈署工作負載：實際操作佈署 Kubernetes 叢集和應用程式。
使用 Azure 入口網站管理叢集：探索 Azure 入口網站提供的管理和監控功能。
成本分析與資源清理：瞭解執行 AKS 叢集的成本，並學習如何清理資源。

在接下來的章節中，我們將探討 Kubernetes 的安全方面，包括身份驗證和授權、准入控制器、網路策略等重要主題。

Kubernetes 安全防護：驗證與授權機制

在現代軟體系統中，驗證（Authentication）與授權（Authorization）是確保系統安全性的根本。驗證是確認使用者身份的過程，通常透過使用者名稱和密碼等機制實作；而授權則決定了已驗證的使用者在系統中的存取許可權。Kubernetes 進一步擴充套件了這兩個概念，引入了根據角色的存取控制（Role-Based Access Control, RBAC），允許管理員定義具有特定許可權的角色，並將這些角色分配給使用者，從而實作細粒度存取控制。

身份驗證與使用者管理

Kubernetes API 伺服器提供了 RESTful 端點來管理叢集，並作為叢集分享狀態的前端。所有與叢集的互動，包括使用者與內部元件，都透過 Kubernetes API 伺服器進行。接下來，我們將探討 Kubernetes 中的驗證機制。

Kubernetes 中的驗證流程

如同高安全性設施，您的 Kubernetes 叢集需要強大的安全措施來保護其資源。這涉及多層次的方法，多個關鍵元件共同協作，如下圖所示：

此圖示展示了請求到 Kubernetes API 的多階段處理流程。

RBAC 模型與存取控制

Kubernetes 提供了多種驗證方式，包括 X509 使用者端憑證、OpenID Connect 權杖等。RBAC 模型允許管理員對叢集資源進行細粒度控制，管理使用者、群組和 ServiceAccounts。接下來，我們將探討 RBAC 模型。

Pod 與容器安全

Pod 和容器本身需要被保護，因為它們執行著可能與敏感資訊互動的工作負載。Kubernetes 提供了一組 securityContext 選項，讓管理員可以宣告容器的特定安全設定，包括強制容器以非 root 身份執行。同樣重要的是網路安全，我們將討論如何使用 NetworkPolicies 在叢集內部隔離和保護 Pod 通訊。

容器執行時期安全

我們將探討 gVisor 和 Kata Containers 作為執行時期的選項，它們在使用者空間核心與系統呼叫之間或每個容器的輕量級虛擬機器環境中引入了更多的安全邊界，分別提供了容器的速度和虛擬機器的安全性。

私有倉函式庫憑證管理

私有倉函式庫憑證是確保叢集內部容器映像檔安全性的關鍵。我們將介紹 Kubernetes 如何安全地處理這些憑證，確保只有授權元件才能存取它們。

在本章中，我們將涵蓋以下主題：

驗證與授權 – 使用者存取控制
准入控制 – 安全策略與檢查
保護 Pod 與容器
管理機密資訊與倉函式庫憑證

技術需求

本章需要以下技術需求：

已佈署的 Kubernetes 叢集，建議使用多節點或根據雲端的 Kubernetes 叢集。
在本地機器上安裝並組態 Kubernetes CLI（kubectl）以管理您的 Kubernetes 叢集。

重點整理

本章探討了 Kubernetes 的進階安全概念和工具，幫助您增強叢集的安全態勢，降低風險，並提供最佳的防禦措施來抵禦潛在的漏洞。透過這些措施，您將能夠在每個層面確保 Kubernetes 佈署的安全性，從身份管理到執行時期隔離，並強化容器化應用的強健性。

程式碼範例與解析

apiVersion: v1
kind: Pod
metadata:
  name: security-context-demo
spec:
  securityContext:
    runAsUser: 1000
    fsGroup: 2000
  volumes:
  - name: sec-ctx-vol
    emptyDir: {}
  containers:
  - name: sec-ctx-demo
    image: busybox
    command: ["sleep", "1h"]
    volumeMounts:
    - name: sec-ctx-vol
      mountPath: /data/demo
    securityContext:
      allowPrivilegeEscalation: false

程式碼解密：

apiVersion 和 kind 定義了 Kubernetes 資源的版本和型別，在此範例中為 Pod。
metadata 部分包含了 Pod 的名稱。
spec 部分定義了 Pod 的規格，包括 securityContext、volumes 和 containers。
securityContext 設定了 Pod 的安全上下文，包括 runAsUser 和 fsGroup，用於指定執行 Pod 的使用者和群組 ID。
volumes 定義了一個名為 sec-ctx-vol 的空目錄卷，用於在容器之間共用資料。
containers 部分定義了一個名為 sec-ctx-demo 的容器，使用 busybox 映象，並執行 sleep 1h 命令。
volumeMounts 將 sec-ctx-vol 卷掛載到容器的 /data/demo 路徑。
容器的 securityContext 設定禁止了許可權提升。

本章節介紹了 Kubernetes 的安全機制，包括驗證、授權、Pod 和容器的安全防護、網路安全、容器執行時期安全以及私有倉函式庫憑證管理。透過這些措施，您可以顯著提高 Kubernetes 叢集的安全性。

Kubernetes 安全防護機制解析

Kubernetes 作為現代化的容器協調平台，其安全性至關重要。為了確保叢集的安全，Kubernetes 實作了多層次的安全防護機制，主要涵蓋四個核心層面：驗證（Authentication）、授權（Authorization）、准入控制（Admission Control）以及稽核（Auditing）。這些機制共同構成了 Kubernetes 的安全防禦體系，有效保護叢集免受未授權存取和潛在威脅。

多層次安全防禦體系

驗證（Authentication）：作為安全防護的第一道防線，驗證機制負責確認存取 Kubernetes API 伺服器的身分。可以將其比喻為守衛檢查進入者的身份證。使用者可能透過密碼、令牌或特殊憑證來證明其授權身分。
授權（Authorization）：一旦身分得到確認，授權機制決定了使用者在叢集內可以執行的操作。可以將其視為授予特定的存取許可權。例如，使用者可能被允許檢視資源但不能修改，或者他們可能被授權在特定區域內建立新資源。
准入控制（Admission Control）：此階段增加了額外的審查層。可以將其比喻為入口處的安全掃描器。准入控制模組可以檢查傳入的請求，確保它們符合預先定義的安全政策，甚至可以修改請求以強制執行特定規則，或拒絕那些構成威脅的請求。
稽核（Auditing）：就像記錄進出安全設施的人員一樣，Kubernetes 中的稽核功能會記錄叢集內的所有活動，包括使用者、應用程式以及控制平面本身的操作。這些日誌對於監控可疑活動和維護安全環境至關重要。

這些安全措施共同作用，形成了一個多層次的防禦系統，確保只有授權使用者能夠存取 Kubernetes 叢集，並且他們的操作符合既定的安全政策。

Kubernetes API 的驗證機制

Kubernetes API 的驗證機制確保只有授權的使用者或服務能夠與叢集中的資源進行互動。每個傳入的請求都會經過一系列驗證模組的處理，這些模組是根據叢集組態進行設定的。

請求型別

對 API 的請求總是以下列之一的形式出現：

與叢集中定義的外部正常使用者或服務帳戶相關聯。
如果叢集組態允許匿名請求，則被視為匿名請求。

驗證過程使用整個 HTTP 請求作為輸入，但通常只分析請求標頭或客戶端憑證。驗證由依賴於叢集組態的驗證模組執行。叢集可能啟用了多個驗證模組，並且每個模組會依序執行，直到其中一個成功。如果請求未能透過驗證，API 伺服器將以 HTTP 狀態碼 401（未授權）回應，或者如果允許匿名請求，則將其視為匿名請求。

匿名請求的處理

匿名請求本質上會被對映到一個名為 system:anonymous 的特殊使用者名稱和一個名為 system:unauthenticated 的群組。這意味著您可以像對待其他使用者或服務帳戶一樣，為這些請求組織對資源的授權。

Kubernetes 中的使用者管理

由於所有在叢集內外的操作都必須透過 Kubernetes API 伺服器，因此這意味著所有這些操作都必須經過驗證過程。這包括內部叢整合員和 Pod 對 API 伺服器的查詢操作。對於您作為叢集的外部使用者，使用 kubectl 命令或直接向 Kubernetes API 伺服器發出的任何請求也將經過驗證過程。

一般使用者與服務帳戶

一般使用者：這些使用者由外部管理，與 Kubernetes 叢集無關。目前，Kubernetes 沒有提供任何物件來表示這些使用者。使用者管理可以簡單到透過靜態使用者密碼檔案傳遞給 API 伺服器，但更推薦的做法是利用現有的身分提供者（IdPs），如 Google、GitHub、Azure Active Directory (AAD) 或 AWS IAM 來管理使用者。透過 OpenID Connect (OIDC) 令牌與 Kubernetes 叢集整合，可以實作無縫的驗證體驗。記住，Kubernetes 中的一般使用者帳戶是全域的，沒有名稱空間限制。
服務帳戶：這些是由 Kubernetes 叢集管理的，並建模為 ServiceAccount 物件。您可以像管理其他資源一樣，使用 kubectl 和 YAML 清單檔案建立和管理服務帳戶。這類別帳戶是為叢整合員或在 Pod 中執行的程式設計的。服務帳戶的憑證會被建立為 Secret，並掛載到 Pod 中，以便容器程式可以使用它們與 Kubernetes API 伺服器通訊。當程式使用服務帳戶令牌進行驗證時，它被視為名為 system:serviceaccount:<namespace>:<serviceAccountName> 的使用者。注意，服務帳戶是有名稱空間的。

Kubernetes 中的驗證方法

多種驗證方法有助於安全地控制對 Kubernetes API 伺服器的存取。為了驗證使用者和服務，可以啟用多種驗證策略。每種策略都適用於不同的使用場景和安全級別。其中包括令牌和憑證，用於驗證與叢集互動的人類使用者和應用程式的身分。Kubernetes API 伺服器的優勢在於它支援多種驗證機制，因此叢集可以根據前述方法進行組態。在接下來的章節中，我們將介紹一些常見的驗證方法，如靜態令牌檔案、服務帳戶令牌、X.509 使用者端憑證和 OpenID Connect 令牌。

常見驗證方法介紹

靜態令牌檔案：一種簡單直接的驗證方法，透過靜態檔案儲存使用者資訊。
服務帳戶令牌：用於 Pod 中的程式與 API 伺服器通訊的驗證。
X.509 使用者端憑證：根據公開金鑰基礎設施（PKI）的驗證方法，提供強大的安全性。
OpenID Connect (OIDC) 令牌：利用 OIDC 協定實作與外部身分提供者的整合，提供靈活且安全的驗證體驗。

透過選擇合適的驗證方法並結合使用，Kubernetes 使用者可以建立一個強壯的安全框架，有效保護叢集資源免受未授權存取。接下來，我們將探討這些驗證方法的具體實作和組態細節。

Kubernetes 安全認證機制解析

Kubernetes 提供了多種使用者認證方式，其中最基本的方法是使用靜態令牌檔案。然而，這種方法由於安全性問題，並不建議在生產環境中使用。

靜態令牌檔案認證

靜態令牌檔案認證方法類別似於 Unix/Linux 系統中的 /etc/shadow 和 /etc/passwd 檔案。需要在 .csv 檔案中定義使用者資訊，每行格式如下：

token,user,uid,"group1,group2,group3"

然後，在啟動 Kubernetes API 伺服器程式時，透過 --token-auth-file 引數指定該檔案。

設定靜態令牌檔案

在 /etc/kubernetes/manifests/kube-apiserver.yaml 檔案中新增以下設定：

spec:
  containers:
  - command:
    - kube-apiserver
    - --advertise-address=192.168.59.154
    - --allow-privileged=true
    - --authorization-mode=Node,RBAC
    - --token-auth-file=/etc/kubernetes/user-tokens.csv
    - --client-ca-file=/var/lib/minikube/certs/ca.crt

使用靜態令牌檔案認證

客戶端需要使用 HTTP Bearer 認證方案，在請求中新增 Authorization: Bearer <token> 標頭。Kubernetes API 伺服器會根據靜態令牌檔案驗證令牌並分配使用者屬性。

使用 kubectl 時，需要修改 kubeconfig 檔案：

$ kubectl config set-credentials <contextUser> --token=<token>

然後，建立並使用具有該使用者的上下文：

$ kubectl config use-context <contextName>

靜態令牌檔案認證的優缺點

此圖示展示了靜態令牌檔案認證的原理：

@startuml
skinparam backgroundColor #FEFEFE
skinparam defaultTextAlignment center
skinparam rectangleBackgroundColor #F5F5F5
skinparam rectangleBorderColor #333333
skinparam arrowColor #333333

title 靜態令牌檔案認證的優缺點

rectangle "HTTP 請求" as node1
rectangle "驗證令牌" as node2
rectangle "匹配使用者" as node3

node1 --> node2
node2 --> node3

@enduml

此圖示說明瞭靜態令牌檔案認證的基本流程。

優點：

易於組態
易於理解

缺點：

不安全，暴露令牌檔案會危及所有叢集使用者
需要手動管理使用者
新增或刪除使用者需要重啟 Kubernetes API 伺服器
輪換令牌需要重啟 Kubernetes API 伺服器
在高用性控制平面中，需要額外努力複製令牌檔案內容到每個控制平面節點

ServiceAccount 令牌認證

ServiceAccount 是 Kubernetes 物件，可以像其他資源一樣使用 kubectl 或原始 HTTP 請求進行管理。ServiceAccount 令牌是 JSON Web 令牌（JWT），可以按需生成或使用 kubectl create token 命令建立。

使用 ServiceAccount 令牌認證

在定義 Pod 時，可以指定使用的 ServiceAccount。JWT 令牌將被注入到容器中，然後容器內的程式可以使用它進行 HTTP Bearer 認證。

spec:
  serviceAccountName: <ServiceAccount 名稱>

ServiceAccount 令牌認證的原理

此圖示展示了 ServiceAccount 令牌認證的原理：

@startuml
skinparam backgroundColor #FEFEFE
skinparam defaultTextAlignment center
skinparam rectangleBackgroundColor #F5F5F5
skinparam rectangleBorderColor #333333
skinparam arrowColor #333333

title ServiceAccount 令牌認證的原理

rectangle "使用 ServiceAccount" as node1
rectangle "驗證 JWT 令牌" as node2
rectangle "授權" as node3

node1 --> node2
node2 --> node3

@enduml

內容解密：

Pod 使用指定的 ServiceAccount。
Kubernetes API 伺服器驗證 JWT 令牌。
驗證透過後，授權存取叢集資源。

每個 Kubernetes 名稱空間都有一個預先建立的預設 ServiceAccount。如果 Pod 未指定 ServiceAccount，則會自動繼承預設 ServiceAccount。

使用 `kubectl` 檢視 Pod 的 ServiceAccount

$ kubectl get pods/<podname> -o yaml

檢查 spec.serviceAccountName 欄位以確認 Pod 的 ServiceAccount。