Kubernetes 安全機制驗證與授權詳解

– 7 分鐘閱讀

Kubernetes 安全機制仰賴驗證和授權兩個核心流程。驗證確認使用者身分，授權則決定使用者可執行的操作。驗證方法包含 Bootstrap Tokens，用於簡化新節點加入叢集，並可與 Kubelet TLS Bootstrapping 搭配使用。授權機制則透過 API 伺服器評估使用者身分和請求屬性，決定是否允許請求。Kubernetes 提供多種授權模式，其中 RBAC 根據角色和許可權管理存取控制，ABAC 則根據屬性定義策略。RBAC 透過角色和角色繫結實作，RoleBinding 和 ClusterRoleBinding 將角色與使用者或群組關聯。理解 HTTP 狀態碼 401（未授權）和 403（禁止）的區別有助於除錯存取問題。

Kubernetes 安全機制：驗證與授權

Kubernetes 的安全機制建立在兩個核心流程上：驗證（Authentication）與授權（Authorization）。驗證過程確認使用者的身分，確保他們是自己所聲稱的身分。授權則是在驗證成功後，決定使用者可以在系統中執行的動作。

驗證方法

Kubernetes 使用多種驗證方法，包括 Bootstrap Tokens。Bootstrap Tokens 是一種特殊的 Secret，用於簡化新節點加入叢集的過程。這些儲存在 kube-system 名稱空間中的短期 Tokens，允許 API 伺服器在初始連線期間驗證 Kubelets（在節點上執行的程式）。這種機制簡化了引導過程，使得加入新節點或從頭建立新叢集變得更加容易。

Bootstrap Tokens 的使用

Bootstrap Tokens 可以與 Kubelet TLS Bootstrapping 搭配使用，以實作安全的通訊。這些 Tokens 可以在有或沒有 kubeadm 工具的情況下使用。有關如何使用 Bootstrap Tokens 和 TLS Bootstrapping 進行驗證的更多資訊，請參閱 Kubernetes 的官方檔案。

授權與 RBAC 簡介

在 Kubernetes 中，API 伺服器會評估使用者的身分以及其他請求屬性，例如特定的 API 端點或正在請求的動作。根據預先定義的策略或外部服務，授權模組決定是否允許或拒絕請求。

授權模式

Kubernetes 提供了多種授權模式，可以透過在啟動 Kubernetes API 伺服器時使用 --authorization-mode 引數來啟用。以下是 Kubernetes 中可用的授權模式：

  • RBAC（Role-Based Access Control）：允許使用角色和許可權來組織存取控制和管理。RBAC 是業界標準之一，不僅適用於 Kubernetes。在 Kubernetes 中，RBAC 是允許的，這意味著沒有拒絕規則。預設情況下，所有操作都被拒絕，您需要定義允許規則。
  • ABAC（Attribute-Based Access Control）：根據使用者、資源和環境的屬性來定義策略。這是一種非常細粒度的存取控制方法。在 Kubernetes 中，這是透過 Policy 物件來建模的。

RBAC 的運作方式

在 Kubernetes 中，RBAC 是透過角色和角色繫結來實作的。您可以定義角色並將其分配給使用者或群組，以授予他們特定的許可權。例如，您可以定義一個角色，允許存取特設定檔案，然後將該角色分配給個別使用者或群組。

RoleBinding 和 ClusterRoleBinding

在 Kubernetes 中，您可以使用 RoleBinding 和 ClusterRoleBinding 物件將角色與使用者或群組關聯起來。這樣，多個使用者可以被分配一個角色，而單個使用者也可以有多個角色。

HTTP 狀態碼的區別

在除錯 Kubernetes 叢集的存取問題時，瞭解 HTTP 狀態碼的區別非常重要：

  • 401（未授權）：表示您未被系統識別，例如提供了錯誤的憑證或使用者不存在。
  • 403（禁止）：表示驗證成功，但您不被允許執行所請求的操作。

程式碼示例

以下是一個 Kubernetes API 伺服器的設定檔範例，展示瞭如何啟用 RBAC 和 Node 授權模式：

# /etc/kubernetes/manifests/kube-apiserver.yaml
spec:
  containers:
  - command:
    - kube-apiserver
    - --advertise-address=192.168.59.154
    - --allow-privileged=true
    - --authorization-mode=Node,RBAC

內容解密：

  • --authorization-mode=Node,RBAC：啟用 Node 和 RBAC 授權模式。
  • Node 授權模式用於驗證節點的身分，而 RBAC 則用於根據角色和許可權控制存取。

Kubernetes 中的安全機制：深入解析 RBAC 模式

Kubernetes 提供了多種授權模式來確保叢集的安全性，其中最為重要的是 Role-Based Access Control（RBAC）模式。本篇文章將探討 RBAC 在 Kubernetes 中的應用，並透過實際範例演示如何設定和管理 RBAC。

Kubernetes 中的授權模式

Kubernetes 提供了多種授權模式，包括 Node、Webhook、AlwaysAllow 和 AlwaysDeny。其中，RBAC 是目前最為廣泛使用的授權模式，因為它提供了彈性和易於管理的特性。

  • Node：這是一種特殊的授權模式，用於授權由 kubelet 發出的 API 請求。
  • Webhook：這種模式與身份驗證的 webhook 類別似，可以定義一個外部服務來處理 HTTP POST 請求，並根據請求的內容決定是否允許或拒絕請求。
  • AlwaysAllow：這種模式允許所有請求，但由於安全問題，僅適用於測試環境。
  • AlwaysDeny：這種模式拒絕所有請求，僅用於測試目的。

RBAC 模式在 Kubernetes 中的應用

RBAC 模式涉及以下幾種型別的 API 資源：

  • Role 和 ClusterRole：定義了一組許可權。每個 Role 中的規則指定了允許哪些動詞（verbs）對哪些 API 資源進行操作。Role 是名稱空間範圍內的，而 ClusterRole 是叢集範圍內的。
  • RoleBinding 和 ClusterRoleBinding：將使用者或一組使用者（或 ServiceAccount）與指定的 Role 相關聯。同樣，RoleBinding 是名稱空間範圍內的，而 ClusterRoleBinding 是叢集範圍內的。

實際範例：設定和管理 RBAC

以下是一個實際範例，演示如何設定和管理 RBAC：

步驟 1：建立一個專用的名稱空間

首先，建立一個名為 rbac-demo-ns 的名稱空間：

# 02_rbac/rbac-demo-ns.yaml
---
apiVersion: v1
kind: Namespace
metadata:
  name: rbac-demo-ns

執行以下命令建立名稱空間：

$ kubectl apply -f 02_rbac/rbac-demo-ns.yaml
namespace/rbac-demo-ns created

步驟 2：建立一個示例 Pod

在相同的名稱空間中建立一個名為 nginx-pod 的 Pod：

$ kubectl apply -f 02_rbac/nginx-pod.yaml
pod/nginx-pod created

步驟 3：建立一個 ServiceAccount

建立一個名為 pod-logger 的 ServiceAccount：

# 02_rbac/pod-logger-serviceaccount.yaml
apiVersion: v1
kind: ServiceAccount
metadata:
  name: pod-logger
  namespace: rbac-demo-ns

執行以下命令建立 ServiceAccount：

$ kubectl apply -f 02_rbac/pod-logger-serviceaccount.yaml
serviceaccount/pod-logger created

步驟 4：建立一個 Role

建立一個名為 pod-reader 的 Role，允許對 pods 資源進行 get、watch 和 list 操作：

# 02_rbac/pod-reader-role.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: rbac-demo-ns
  name: pod-reader
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "watch", "list"]

執行以下命令建立 Role：

$ kubectl apply -f 02_rbac/pod-reader-role.yaml
role.rbac.authorization.k8s.io/pod-reader created

#### 內容解密：

此 Role 定義了對 pods 資源的操作許可權，包括 get、watch 和 list。其中，apiGroups 指定了核心 API 群組。

步驟 5：建立一個 Pod 並執行查詢操作

建立一個名為 pod-logger-app 的 Pod，並使用 pod-logger ServiceAccount：

# 02_rbac/pod-logger-app.yaml
apiVersion: v1
kind: Pod
metadata:
  name: pod-logger-app
  namespace: rbac-demo-ns
spec:
  serviceAccountName: pod-logger
  containers:
  - name: logger
    image: quay.io/iamgini/k8sutils:debian12
    command:

#### 內容解密：

此 Pod 使用了 pod-logger ServiceAccount，該 ServiceAccount 將被賦予 pod-reader Role 的許可權。Pod 中的容器將執行查詢操作，以取得 pods 資源的列表。

此圖示說明：

此圖示展示了 Kubernetes 中的 RBAC 工作流程。當 Kubernetes API Server 接收到請求時，授權模組會根據 RBAC 設定檢查請求的合法性。Role 定義了許可權，而 RoleBinding 將 Role 繫結到使用者或 ServiceAccount 上。最終，使用者或 ServiceAccount 可以根據其繫結的 Role 執行相應的操作。

Kubernetes 安全機制：RBAC 與 Admission Control 詳解

Kubernetes 提供了多層次的安全機制，以確保叢集資源的安全性和存取控制。本文將探討 Kubernetes 中的兩大關鍵安全元件：Role-Based Access Control（RBAC）與 Admission Control。

使用 RBAC 進行資源存取控制

RBAC 是 Kubernetes 中用於管理使用者和服務帳戶對資源存取許可權的重要機制。透過 RBAC，我們可以精確控制哪些使用者或服務帳戶可以對特定的資源執行特定的操作。

實戰演練：組態 RBAC 許可權

首先，我們建立一個名為 rbac-demo-ns 的名稱空間，並在其中佈署一個名為 nginx-pod 的 Pod。同時，我們建立一個名為 pod-logger-app 的 Pod，該 Pod 使用 pod-logger 服務帳戶，並定期查詢 Kubernetes API 以取得 rbac-demo-ns 名稱空間中的 Pod 清單。

$ kubectl apply -f 02_rbac/pod-logger-app.yaml
pod/pod-logger-app created
$ kubectl get po -n rbac-demo-ns
NAME           READY   STATUS    RESTARTS   AGE
nginx-pod      1/1     Running   0          15m
pod-logger-app 1/1     Running   0          9s

使用服務帳戶與 RBAC 進行 API 請求

pod-logger-app Pod 中的容器會定期查詢 Kubernetes API，並使用掛載在 /var/run/secrets/kubernetes.io/serviceaccount/token 的 bearer token 進行身份驗證。

$ kubectl exec -it -n rbac-demo-ns pod-logger-app -- bash
root@pod-logger-app:/# ls -l /var/run/secrets/kubernetes.io/serviceaccount/
total 0
lrwxrwxrwx 1 root root 13 Jul 14 03:33 ca.crt -> ..data/ca.crt
lrwxrwxrwx 1 root root 16 Jul 14 03:33 namespace -> ..data/namespace
lrwxrwxrwx 1 root root 12 Jul 14 03:33 token -> ..data/token

組態 RoleBinding 以授權存取許可權

預設情況下，pod-logger-app Pod 無法成功查詢 Pod 清單，因為 pod-logger 服務帳戶尚未與 pod-reader Role 繫結。我們需要建立一個 RoleBinding 以授權 pod-logger 服務帳戶使用 pod-reader Role。

# 02_rbac/read-pods-rolebinding.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: read-pods
  namespace: rbac-demo-ns
subjects:
- kind: ServiceAccount
  name: pod-logger
  namespace: rbac-demo-ns
roleRef:
  kind: Role
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io

$ kubectl apply -f 02_rbac/read-pods-rolebinding.yaml
rolebinding.rbac.authorization.k8s.io/read-pods created

在套用 RoleBinding 後，pod-logger-app Pod 可以成功查詢 Pod 清單。

Admission Control：安全策略與檢查

Admission Control 是 Kubernetes 中的另一個重要安全機制，用於在資源建立、修改或刪除之前對請求進行驗證或修改。Admission Control 可以分為兩種型別：Validation Controllers 和 Mutation Controllers。

Validation Controllers 與 Mutation Controllers

  • Validation Controllers：驗證請求是否符合預定的安全策略，如果不符合，則拒絕該請求。
  • Mutation Controllers：在請求被持久化之前對其進行修改，例如新增安全註解或調整資源限制。

二階段 Admission Process

Kubernetes 的 Admission Control 採用二階段處理流程：

  1. Mutation Phase：對請求進行必要的修改或增強。
  2. Validation Phase：驗證請求是否符合所有必要的安全和策略要求。

透過這兩個階段，Kubernetes 可以確保只有符合安全策略的資源才能被建立或修改。

玄貓 BlackCat

玄貓 BlackCat

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