Cloud Custodian Kubernetes 准入控制實踐

– 6 分鐘閱讀

Kubernetes 已成為容器協調標準，而 Cloud Custodian 則提供強大的雲端資源治理能力。兩者整合，能有效提升 Kubernetes 叢集的管理效率和安全性。本文將探討 Cloud Custodian 的 c7n-kube 和 c7n-kates 元件，如何實作 Kubernetes 准入控制，並搭配實際案例與組態說明，讓讀者瞭解如何運用 Cloud Custodian 強化 Kubernetes 資源管理。文章涵蓋策略驗證流程、變更性策略的實作方式，以及 c7n-kates 元件的組態與運作原理。同時，也提供最佳實踐建議，例如策略設計、效能考量和安全性建議，協助讀者更好地運用 Cloud Custodian 管理 Kubernetes 叢集。

Cloud Custodian與Kubernetes的整合應用：深入解析與實踐

前言

在現代化的雲端原生應用開發與管理中，Kubernetes已成為事實上的容器協調標準。而Cloud Custodian作為一個強大的雲端資源治理工具，其與Kubernetes的整合應用為企業帶來了更高效、更安全的資源管理方案。本文將探討Cloud Custodian在Kubernetes中的實踐應用，特別是在准入控制（Admission Control）方面的實作與組態。

Cloud Custodian在Kubernetes中的准入控制機制

准入控制的基本概念

Kubernetes的准入控制機制允許管理員在資源建立、更新或刪除時進行干預。Cloud Custodian透過其c7n-kube元件實作了這一機制，能夠對Kubernetes資源進行策略驗證和變更。

策略驗證例項分析

以下是一個典型的准入控制策略驗證示例：

image: registry.k8s.io/pause:3.1
imagePullPolicy: Always

當我們嘗試建立一個不符合預定義策略的Pod時，c7n-kube會拒絕該請求並傳回詳細的錯誤資訊：

$ kubectl apply -f test
namespace/policy-test created
Warning: warn-all-pods:
Error from server: error when creating "test/k8s-manifest.yaml":
admission webhook "admission.cloudcustodian.io" denied the request:
Failed admission due to policies:[{"name": "missing-required-labels-pods",
"description": "The following labels are required on all pods:\n\napp\nbilling\nenv\nowner\n"}]

內容解密：

  1. 該錯誤訊息表明Pod建立請求被c7n-kube攔截並拒絕
  2. 策略missing-required-labels-pods要求所有Pod必須包含特定的標籤：app、billing、env和owner
  3. c7n-kube透過Mutating Webhook機制實作了驗證功能，無需額外的Validating Admission Controller

變更性策略（Mutating Policies）實作

策略組態詳解

c7n-kube支援變更性策略，能夠在資源建立或更新時自動修改其屬性。以下是一個典型的變更性策略組態：

policies:
- name: 'auto-label-userinfo'
  resource: 'k8s.pod'
  mode:
    type: k8s-admission
    on-match: allow
  operations:
  - CREATE
  - UPDATE
  filters:
  - type: value
    key: metadata.labels.test
    value: c7n
  actions:
  - type: auto-label-user
    key: owner

內容解密：

  1. 名稱為auto-label-userinfo的策略針對k8s.pod資源進行操作
  2. 該策略在Pod建立或更新時觸發，且僅當Pod包含test=c7n標籤時生效
  3. auto-label-user動作會自動為符合條件的Pod新增擁有者資訊標籤

策略生效驗證

當我們應用上述策略並建立符合條件的Pod時，c7n-kube會自動修改Pod的標籤：

$ kubectl -n test get po test-pod-1 -o=jsonpath='{.metadata.labels}'
{"owner":"minikube-user","test":"c7n","touched-by":"c7n-kube"}

內容解密：

  1. Pod的metadata.labels被成功更新，包含了預期的標籤資訊
  2. touched-by: c7n-kube標籤表明該Pod已被c7n-kube處理過

c7n-kates元件詳解

元件功能概述

c7n-kates是Cloud Custodian用於處理Kubernetes API請求的核心元件。它透過動態准入控制Webhook機制與Kubernetes API伺服器進行互動。

元件組態分析

c7n-kates的典型啟動引陣列態如下：

spec:
  containers:
  - args:
    - --host=0.0.0.0
    - --port=8443
    - --policy-dir=/policies
    - --on-exception=warn
    - --endpoint=/mutation
    - --cert=/cert/tls.crt
    - --ca-cert=/cert/ca.crt
    - --cert-key=/cert/tls.key
    command:
    - c7n-kates
    image: cloudcustodian/c7n:latest

內容解密：

  1. c7n-kates監聽8443埠並使用TLS證書進行安全通訊
  2. 策略組態儲存在/policies目錄下
  3. 當發生異常時，元件會以警告模式處理

最佳實踐與注意事項

  1. 策略設計最佳實踐

    • 明確定義資源選擇條件，避免過度寬泛的匹配規則
    • 謹慎使用變更性策略，確保其不會破壞應用原本的功能

  2. 效能考量

    • 將c7n-kates佈署在叢集內部，以降低網路延遲影響
    • 合理規劃策略數量，避免過多的策略導致效能下降

  3. 安全性建議

    • 使用TLS加密c7n-kates的通訊過程
    • 定期輪換證書和審核策略組態

  4. 增強策略功能

    • 探索更多變更性策略的使用場景
    • 開發更複雜的資源間關聯策略

  5. 提升維運效率

    • 建立策略變更的版本控制機制
    • 開發自動化的策略測試框架

  6. 加強安全保障

    • 實作更細粒度的許可權控制機制
    • 建立安全事件的自動回應流程

透過持續的最佳化和改進，Cloud Custodian與Kubernetes的整合將為企業帶來更大的價值。未來，我們可以期待看到更多根據這一整合的創新應用和實踐。以下是相關技術發展趨勢的Mermaid流程圖：

  graph LR
    A[現有整合方案] -->|持續最佳化| B[增強策略功能]
    A -->|提升效率| C[自動化維運]
    A -->|加強安全| D[細粒度許可權控制]
    B --> E[更多變更性策略]
    C --> F[策略版本控制]
    D --> G[安全事件自動回應]

圖表翻譯： 此圖示呈現了Cloud Custodian與Kubernetes整合未來的發展方向。主要包含三個方面：增強策略功能、提升維運效率和加強安全保障。這些方向將推動技術的不斷進步和創新。

綜上所述，Cloud Custodian與Kubernetes的整合不僅提升了資源管理的效率，也為企業的安全合規提供了有力保障。透過不斷的最佳實踐和技術創新，我們可以期待這一領域在未來取得更大的發展。

Kubernetes 與 Cloud Custodian 的整合：動態許可控制實務

在現代化的雲端原生應用中，授權決策（AuthZ decisions）通常是時間敏感的使用案例。因此，將策略決策點（Policy Decision Point）盡可能靠近策略執行點（Policy Enforcement Point）是一個最佳實踐。本文將探討如何使用 Cloud Custodian 與 Kubernetes 整合，實作動態的許可控制。

啟動 c7n-kates 伺服器

要啟動 c7n-kates 伺服器，可以使用以下命令：

$ c7n-kates --host 10.0.2.2 --port 8443 --policy-dir policies \
--on-exception warn --endpoint https://c7n-admission:8443/mutation \
--cert config/secrets/server.crt \
--cert-key config/secrets/server.key \
--ca-cert config/secrets/ca.crt \
--generate > ext-webhook.yaml

內容解密：

  • --host 和 --port 指定了 c7n-kates 伺服器的主機和埠。
  • --policy-dir 指定了策略檔案的目錄。
  • --on-exception 指定了當發生例外時的行為。
  • --endpoint 指定了 webhook 的端點。
  • --cert、--cert-key 和 --ca-cert 指定了 TLS 憑證相關的檔案。
  • --generate 選項用於生成 Kubernetes manifest 檔案，以便組態 webhook 連線到 c7n-kates 伺服器。

生成 Kubernetes Manifest 檔案

使用 --generate 選項後，生成的 Kubernetes manifest 檔案如下：

apiVersion: admissionregistration.k8s.io/v1
kind: MutatingWebhookConfiguration
metadata:
  labels:
    app.kubernetes.io/component: AdmissionController
    app.kubernetes.io/instance: c7n-kates
    app.kubernetes.io/managed-by: c7n
    app.kubernetes.io/name: c7n-kates
    app.kubernetes.io/part-of: c7n_kube
    app.kubernetes.io/version: 0.2.27
  name: c7n-admission
webhooks:
- admissionReviewVersions:
  - v1
  - v1beta1
  clientConfig:
    caBundle: LS0tLS1CRUdJT...
    url: https://c7n-admission:8443/mutation
  failurePolicy: Fail
  name: admission.cloudcustodian.io
  rules:
  - apiGroups:
    - ''
    apiVersions:
    - v1
    operations:
    - CREATE
    - UPDATE
    resources:
    - pods
    scope: '*'
  sideEffects: None

內容解密：

  • admissionReviewVersions 指定了支援的 AdmissionReview 版本。
  • clientConfig 組態了 webhook 的客戶端組態，包括 CA bundle 和 URL。
  • failurePolicy 指定了當 webhook 失敗時的處理策略。
  • rules 定義了 webhook 的觸發規則，包括 API 群組、版本、操作和資源。

生成 TLS 藝術品

為了使 Kubernetes API 伺服器能夠與 c7n-kates 伺服器進行安全通訊，需要生成 TLS 藝術品。以下是一個生成 TLS 藝術品的指令碼：

#!/usr/bin/env bash
trap 'catch $? $LINENO' ERR
catch() {
  echo "Error $1 occurred on $2"
}
SERVER_CONF_DIR=${1:-"server"}
SECRETS_DIRECTORY="secrets"
if [ ! -d "$SERVER_CONF_DIR" ]; then
  echo "$SERVER_CONF_DIR not found, process aborted"
  exit 99
fi
if [ ! -d "$SECRETS_DIRECTORY" ]; then
  mkdir -p $SECRETS_DIRECTORY
fi
rm -f $SECRETS_DIRECTORY/*

openssl genrsa -out $SECRETS_DIRECTORY/ca.key 2048
openssl req -x509 -new -nodes -sha256 -key $SECRETS_DIRECTORY/ca.key \
-days 365 -out $SECRETS_DIRECTORY/ca.crt -subj /CN=admission_ca 2>&1
openssl genrsa -out $SECRETS_DIRECTORY/server.key 2048
openssl req -new -key $SECRETS_DIRECTORY/server.key -sha256 -out \
$SECRETS_DIRECTORY/server.csr -subj /CN=c7n-admission \
-config $SERVER_CONF_DIR/server.conf 2>&1
openssl x509 -req -days 365 -in $SECRETS_DIRECTORY/server.csr -sha256 \
-CA $SECRETS_DIRECTORY/ca.crt -CAkey $SECRETS_DIRECTORY/ca.key \
-CAcreateserial -out $SECRETS_DIRECTORY/server.crt -days 100000 -extensions \
v3_ext -extfile $SERVER_CONF_DIR/server.conf

內容解密：

  • 使用 OpenSSL 生成 CA 金鑰和憑證。
  • 生成伺服器金鑰和憑證籤名請求（CSR）。
  • 使用 CA 金鑰簽署伺服器 CSR，生成伺服器憑證。

測試 Webhook 組態

測試 webhook 組態是否正確，可以檢視 c7n-kates 伺服器的日誌：

10.0.2.2 - - [09/Jul/2023 20:03:27] "POST /mutation?timeout=10s HTTP/1.1"
200 - 2023-07-09 20:03:27,681: c7n_kube.server:INFO {"apiVersion":
"admission.k8s.io/v1", "kind": "AdmissionReview", "response": {"allowed":
true, "warnings": ["warn-all-pods:"], "uid":
"e623ea31-d500-4208-bb16-d7cd5a08088f", "status": {"code": 200, "message":
"OK"}, "patchType": "JSONPatch", "patch": "W3sib3AiOiAiY..."}}

圖表翻譯：

此圖示呈現了c7n-kates伺服器處理變更許可控制的流程。當Kubernetes API伺服器接收到建立或更新Pod的請求時，它會將請求轉發給c7n-kates伺服器。c7n-kates伺服器根據預先定義的策略評估請求，如果請求符合策略，則傳回允許的回應，否則傳回拒絕的回應。

  sequenceDiagram
    participant Kubernetes API Server as "Kubernetes API Server"
    participant c7n-kates Server as "c7n-kates Server"
    Kubernetes API Server->>c7n-kates Server: AdmissionReview Request
    c7n-kates Server->>c7n-kates Server: Evaluate Policies
    c7n-kates Server->>Kubernetes API Server: AdmissionReview Response
    Kubernetes API Server->>Kubernetes API Server: Apply Response
玄貓

玄貓

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