Kubernetes Pod 安全策略實踐與授權控制

Kubernetes 的 Pod 安全策略對於叢集的穩定和安全至關重要。本文從過往的 Pod Security Policies（PSP）談起，引出現在的 Pod Security Admission（PSA）和 Pod Security Standards（PSS），並說明如何設定不同層級的安全策略。PSA 提供 Enforce、Warn 和 Audit 三種模式，讓管理員可以彈性地控管 Pod 的安全性。此外，Policy as Code（PaC）的整合能更進一步提升安全性，讓策略管理更具彈性。除了 Pod 安全策略，Kubernetes 也提供授權控制（AuthZ）機制，透過 Webhook 模式，可以整合外部的 PaC 工具，例如 Open Policy Agent（OPA），實作更細緻的存取控制，提升整體安全性。

Kubernetes 中的 Pod 安全策略與實踐

在 Kubernetes 環境中，Pod 安全是確保叢集穩定性和安全性的重要環節。隨著 Kubernetes 的發展，Pod 安全策略（Pod Security Policies, PSP）曾經是管理 Pod 安全性的主要手段。然而，由於其複雜性和使用者經驗不佳，PSP 已被移除，取而代之的是 Pod Security Admission（PSA）和 Pod Security Standards（PSS）。

In-Tree 與 Out-of-Tree 功能

在探討 PSA 和 PSS 之前，瞭解 Kubernetes 中的 in-tree 和 out-of-tree 功能是非常重要的。In-tree 功能是指內建於 Kubernetes 原始碼中的功能，無需額外安裝即可使用。相反，out-of-tree 功能則需要額外安裝或整合，通常由 Kubernetes 生態系統提供。

PSP 曾經是 in-tree 功能，而許多 Policy as Code（PaC）解決方案則是 out-of-tree 的，它們提供了更靈活和強大的策略管理能力。

Pod Security Admission (PSA) 與 Pod Security Standards (PSS)

PSA 是 Kubernetes 的一個准入控制器，用於實施 PSS。PSS 定義了三種安全級別：privileged、baseline 和 restricted，分別對應不同的安全需求。PSA 透過三種模式來實施 PSS：Enforce、Warn 和 Audit。

PSA 模式詳解

1. Enforce：違反策略的 Pod 將被阻止建立。

   pod-security.kubernetes.io/enforce: baseline
   

2. Warn：違反策略的 Pod 將觸發警告，通知使用者可能存在的安全風險。

   pod-security.kubernetes.io/warn: restricted
   

3. Audit：違反策略的 Pod 將被記錄在稽核日誌中，用於事後分析和稽核。

   pod-security.kubernetes.io/audit: restricted
   

組態 PSA 和 PSS

要啟用 PSA 和 PSS，需要在 Kubernetes Namespace 上設定相應的標籤。以下是一個範例組態：

apiVersion: v1
kind: Namespace
metadata:
  name: policy-test
labels:
  pod-security.kubernetes.io/enforce: baseline
  pod-security.kubernetes.io/audit: restricted
  pod-security.kubernetes.io/warn: restricted

混合使用 PSA 模式和 PSS 級別

可以根據具體需求混合使用不同的 PSA 模式和 PSS 級別。例如，以下組態強制執行 baseline 級別的安全策略，同時對 restricted 級別進行稽核和警告：

apiVersion: v1
kind: Namespace
metadata:
  name: policy-test
labels:
  pod-security.kubernetes.io/enforce: baseline
  pod-security.kubernetes.io/audit: restricted
  pod-security.kubernetes.io/warn: restricted

#### 內容解密：

此組態展示瞭如何在 Kubernetes Namespace 中應用不同的 PSA 模式和 PSS 級別。其中：

• pod-security.kubernetes.io/enforce: baseline 表示強制執行 baseline 級別的安全策略，任何違反此策略的 Pod 將被阻止建立。
• pod-security.kubernetes.io/audit: restricted 和 pod-security.kubernetes.io/warn: restricted 表示對 restricted 級別進行稽核和警告，幫助管理員瞭解可能存在的安全風險。

PaC 與 PSA/PSS 的協同工作

雖然 PSA 和 PSS 提供了一定程度的安全控制，但 PaC 解決方案提供了更靈活和強大的策略管理能力。兩者並不互相排斥，可以協同工作以增強叢集的安全性和使用者經驗。

例如，PaC 可以用於強制執行 PSA/PSS 的標籤模型，確保 Namespace 正確組態安全策略。此外，PaC 可以透過動態准入控制器來強制執行更複雜的策略，從而彌補 PSA 和 PSS 的不足。

隨著 Kubernetes 的不斷發展，Pod 安全將繼續演進。未來可能會出現更多強大的安全工具和策略，以滿足日益增長的安全需求。作為 Kubernetes 使用者，瞭解和掌握這些新工具和新技術，將有助於更好地保護叢集和應用程式的安全。

  graph LR;
    A[Kubernetes叢集] --> B[PSA];
    A --> C[PSS];
    A --> D[PaC];
    B --> E[Enforce模式];
    B --> F[Warn模式];
    B --> G[Audit模式];
    C --> H[Privileged級別];
    C --> I[Baseline級別];
    C --> J[Restricted級別];
    D --> K[動態准入控制器];
    D --> L[自定義安全策略];

圖表翻譯：

此圖表展示了 Kubernetes 叢集中的安全元件及其相互關係。其中：

• PSA（Pod Security Admission）透過三種模式（Enforce、Warn、Audit）來實施安全控制。
• PSS（Pod Security Standards）定義了三種安全級別（Privileged、Baseline、Restricted）。
• PaC（Policy as Code）提供了動態准入控制器和自定義安全策略，以增強叢集的安全性。

Kubernetes 原生策略管理功能深入解析

Kubernetes 持續演進，不斷強化其原生策略管理（Policy as Code, PaC）功能。本文將探討 Kubernetes 的原生 PaC 解決方案，包括 Pod Security Admission (PSA) 和 Validating Admission Policy (VAP)，並分析其在實際應用中的價值。

Pod Security Admission (PSA) 與 Pod Security Standards (PSS)

Kubernetes 提供內建的 Pod Security Admission (PSA) 功能，結合 Pod Security Standards (PSS) 來實施 Pod 安全策略。PSA 是 Kubernetes 的內建元件，無需額外安裝。PSS 定義了三種安全標準：

1. Privileged（寬鬆模式）：允許最高許可權，適用於需要特權存取的系統元件。
2. Baseline（基本模式）：提供基本的安全防護，限制某些特權操作。
3. Restricted（嚴格模式）：實施最嚴格的安全限制，適用於安全性要求極高的應用。

PSA 組態範例

apiVersion: v1
kind: Namespace
metadata:
  name: example-namespace
  labels:
    pod-security.kubernetes.io/enforce: baseline
    pod-security.kubernetes.io/audit: restricted
    pod-security.kubernetes.io/warn: restricted

內容解密：

此組態為 example-namespace 名稱空間設定了三種不同的安全執行模式：

• enforce：強制執行 baseline 策略，若 Pod 不符合規範則拒絕建立。
• audit：稽核層級設為 restricted，不符合規範的操作會被記錄在稽核日誌中。
• warn：對不符合 restricted 策略的 Pod 發出警告。

Validating Admission Policy (VAP)：Kubernetes 的原生 PaC 解決方案

自 Kubernetes v1.28 起，Validating Admission Policy (VAP) 成為 Beta 功能。VAP 提供了一種高度可組態的內建 PaC 解決方案，用於驗證叢集資源。與 PSA 不同，VAP 不僅限於 Pod 資源，還可應用於其他 Kubernetes 資源。

VAP 的主要元件

1. ValidatingAdmissionPolicy：定義策略邏輯和驗證規則，使用 Common Expression Language (CEL) 表示式。
2. ValidatingAdmissionPolicyBinding：將策略繫結到特定範圍（如名稱空間）並連結引數資源。
3. ParameterResource：提供策略所需的引陣列態，使策略定義與組態分離。

VAP 範例：佈署歷史記錄限制

以下範例展示如何使用 VAP 限制 Deployment 資源的 revisionHistoryLimit 屬性。

# ValidatingAdmissionPolicy 資源定義
apiVersion: admissionregistration.k8s.io/v1alpha1
kind: ValidatingAdmissionPolicy
metadata:
  name: deploy-history-policy.example.com
spec:
  failurePolicy: Fail
  paramKind:
    apiVersion: rules.example.com/v1
    kind: HistoryLimit
  matchConstraints:
    resourceRules:
    - apiGroups: ["apps"]
      apiVersions: ["v1"]
      operations: ["CREATE", "UPDATE"]
      resources: ["deployments"]
  validations:
  - expression: "object.spec.revisionHistoryLimit <= params.historyLimit"
    reason: Invalid

內容解密：

此 VAP 資源定義了一個策略，用於檢查 Deployment 的 revisionHistoryLimit 是否小於或等於指定的 historyLimit。若驗證失敗，則 API 操作會被拒絕。

# ParameterResource 定義
apiVersion: rules.example.com/v1
kind: HistoryLimit
metadata:
  name: deploy-history-limit.example.com
historyLimit: 3

內容解密：

此引數資源定義了 historyLimit 的值為 3，即允許的最大歷史記錄數量。

# ValidatingAdmissionPolicyBinding 繫結定義
apiVersion: admissionregistration.k8s.io/v1alpha1
kind: ValidatingAdmissionPolicyBinding
metadata:
  name: deploy-history-binding.example.com
spec:
  policyName: deploy-history-policy.example.com
  paramsRef:
    name: deploy-history-limit.example.com
  matchResources:
    namespaceSelectors:
    - key: environment
      operator: In
      values: ["policy-test"]

內容解密：

此繫結將 deploy-history-policy.example.com 策略應用於 environment 標籤值為 policy-test 的名稱空間，並使用 deploy-history-limit.example.com 引數資源。

VAP 的優勢與未來發展

VAP 利用 CEL 提供強大的驗證功能，且無需額外安裝，具有以下優勢：

• 原生整合：作為 Kubernetes 內建功能，無需額外安裝或維護。
• 高度可組態：支援多種資源型別和自定義驗證邏輯。
• 靈活性：可根據不同名稱空間或資源型別應用不同的策略。

此外，Kubernetes 社群正在開發 MutatingAdmissionPolicy 功能（KEP-3962），預計在 v1.31 版本中推出，將進一步增強 Kubernetes 的 PaC 能力。

隨著 Kubernetes 不斷發展，其原生 PaC 功能將持續增強。未來的發展方向可能包括：

• 更豐富的驗證規則：支援更多自定義驗證邏輯和複雜條件判斷。
• 更完善的 MutatingAdmissionPolicy：提供更靈活的資源變更策略。
• 更好的整合與相容性：與其他 Kubernetes 功能（如 OPA、Kyverno 等）深度整合，提供統一的 PaC 管理體驗。

透過持續關注 Kubernetes 的最新動態，企業可以更好地利用其原生 PaC 功能，提升叢集的安全性和管理效率。以下是Mermaid圖表示Kubernetes PaC的流程圖：

  graph LR;
    A[Kubernetes API 請求] --> B{Validating Admission Policy};
    B -->|驗證透過| C[資源建立/更新];
    B -->|驗證失敗| D[請求被拒絕];
    C --> E[資源佈署完成];
    D --> F[傳回錯誤訊息];

圖表翻譯： 此圖展示了Kubernetes中使用Validating Admission Policy（VAP）處理API請求的流程。首先，所有對Kubernetes API的請求都會被VAP攔截並進行驗證。如果請求透過驗證，則允許資源建立或更新；如果驗證失敗，則請求被拒絕並傳回錯誤訊息。整個流程確保了叢集中的資源符合預先定義的安全與合規策略。

Kubernetes 中的授權控制與 Policy as Code（PaC）整合

在前面的章節中，我們探討瞭如何使用 Policy as Code（PaC）進行 Kubernetes 的准入控制。現在，讓我們將焦點轉移到授權控制（AuthZ），並探討如何利用 PaC 實作 Kubernetes 中的 AuthZ 使用案例。

AuthZ Webhook 模式

Kubernetes 的授權控制旨在控制外部和內部客戶端對 Kubernetes API 伺服器的存取。Kubernetes 支援多種授權模式，包括節點層級存取、透過 Webhook 整合的客戶端授權，以及我們在第 3 章中探討的 RBAC 和 ABAC。

與主要整合到動態准入控制器的 PaC 不同，AuthZ Webhook 整合是在叢集啟動期間於 API 伺服器上組態的。這種授權方式不像 RBAC 那樣被廣泛使用，但可以與 RBAC 結合以實作更細粒度的安全控制。Webhook 模式在與外部身份驗證提供者整合時非常有效。

AuthZ 決策

用於 AuthZ Webhook 的組態 YAML 重用了 kubeconfig 格式，其中 clusters 節點用於組態 AuthZ 服務（也稱為授權者），這些服務由 API 伺服器呼叫。users 節點用於組態 API 伺服器，以便與 Webhook 服務進行安全通訊。這意味著可以為 API 伺服器組態多個（連結的）授權者，以進行 AuthZ 決策。

授權決策的可能結果

// 允許存取的決策，回應中無需訊息
{
  "apiVersion": "authorization.k8s.io/v1",
  "kind": "SubjectAccessReview",
  "status": {
    "allowed": true
  }
}

// 不允許存取但不拒絕的決策，其他授權者仍可進行決策
{
  "apiVersion": "authorization.k8s.io/v1",
  "kind": "SubjectAccessReview",
  "status": {
    "allowed": false,
    "reason": "非管理員使用者無法存取管理員名稱空間。"
  }
}

// 拒絕存取的決策
{
  "apiVersion": "authorization.k8s.io/v1",
  "kind": "SubjectAccessReview",
  "status": {
    "allowed": false,
    "denied": true,
    "reason": "非管理員使用者無法存取管理員名稱空間。"
  }
}

AuthZ Webhook 與 PaC 的整合

由於 JSON 在 API 伺服器和 AuthZ 服務之間交換，因此很容易想像如何使用 PaC 工具為 API 伺服器做出 AuthZ 決策。關鍵在於啟動 API 伺服器並組態 AuthZ Webhook，而不會在組態 AuthZ Webhook 之前阻止任何必要的變更。

一個最佳實踐是將決策引擎盡可能靠近決策點，以減少網路延遲並提高解決方案的穩健性。在叢集內執行 PaC 引擎，並使用多個 Pod，可以提高容錯能力。

示例政策

以下是一個 OPA 策略範例，用於根據 SubjectAccessReview 物件做出授權決策，拒絕非管理員使用者存取管理員名稱空間：

# OPA 策略：限制對管理員名稱空間的存取
package k8s.authz

import future.keywords.in

# 這裡寫入策略規則

策略實施與 DaemonSet 組態

此解決方案使用 kind、OPA 和 kubeadm 示範瞭如何在 Kubernetes 控制平面節點上使用 DaemonSet 資源執行 OPA。該組態為前端多個 OPA Pod 的 Kubernetes Service 資源設定了靜態 IP。

# DaemonSet 組態範例
apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: opa
spec:
  selector:
    matchLabels:
      name: opa
  template:
    metadata:
      labels:
        name: opa
    spec:
      containers:
      - name: opa
        image: openpolicyagent/opa:latest
        # 其他組態...

圖表翻譯：

此圖示展示了使用 OPA 的 AuthZ webhook 組態。

• 圖中顯示了 Kubernetes 控制平面節點上的 OPA Pod。
• 圖中展示了前端 OPA Pod 的 Kubernetes Service 資源。
• 圖中說明瞭 API 伺服器如何與 OPA 服務互動以進行授權決策。

詳細內容解密：

上述範例展示瞭如何使用 OPA 和 DaemonSet 在 Kubernetes 中實作 AuthZ webhook。透過這種方式，可以將授權決策引擎佈署在叢集內，提高安全性和效能。

• 程式碼部分展示了 OPA 策略和 DaemonSet 組態的基本結構。
• 策略規則用於定義授權決策邏輯，例如拒絕非管理員使用者存取特定名稱空間。
• DaemonSet 組態用於在 Kubernetes 控制平面節點上佈署 OPA Pod。
• 圖表部分展示了整個架構的概覽，包括 API 伺服器、OPA Pod 和 Kubernetes Service 資源之間的互動。