介紹
Kubernetes Admission Controller 是一段程式碼,在物件(object, 例如 Pod、Service 等)被寫入persistence storage (etcd),以及 kubernetes request 被驗證 (authenticated) 和授權 (authorized) 之後,攔截對 Kubernetes API 的 request,並對其變更、驗證。

Admission Controller 主要分為兩種類型:Mutating Admission 和 Validating Admission。
Mutating Admission
在物件被儲存進 etcd 之前修改其屬性。例如,可以自動新增缺少的欄位或根據某些規則修改物件。
Validating Admission
驗證請求的合法性,確保請求符合集群的策略和安全規範。例如,禁止特定的映像或限制資源的使用。
內建的 Admission Controller
NamespaceLifecycle: 確保資源只能在有效的命名空間中創建ResourceQuota: 強制執行資源配額的限制LimitRanger: 強制執行 Pod 和 Container 的資源限制ServiceAccount: 自動為 Pod 指派 ServiceAccount
自定義 Admission Webhook
- 在 Kubernetes 上註冊一個 webhook config
- 兩種 kind:
ValidatingWebhookConfiguration、MutatingWebhookConfiguration
- 兩種 kind:
- 起一個 HTTP server 處理 api-server 的內容
範例
apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingWebhookConfiguration
metadata:
name: "pod-policy.example.com"
webhooks:
- name: "pod-policy.example.com"
rules:
- apiGroups: [""] # 攔截資源的 Group:"" 表示 core、"*" 表示所有
apiVersions: ["v1"] # 攔截資源的版本號
operations: ["CREATE"] # 攔截什麼樣的請求
resources: ["pods"] # 攔截的資源
scope: "Namespaced" # 生效的範圍,cluster 或 namespace,"*" 表示沒有範圍限制
clientConfig: # 我們部屬的 webhook 服務
service: # service 是在 cluster-in 模式
namespace: "example-namespace"
name: "example-service"
port: 443
path: "/validate" # path 是對應驗證的端點
caBundle: "Ci0tLS0tQk...<base64-encoded PEM bundle containing the CA that signed the webhook's serving certificate>...tLS0K"
admissionReviewVersions: ["v1", "v1beta1"]
sideEffects: None
timeoutSeconds: 5 # 1-30s,表示 api 的逾時時間apiVersion: admissionregistration.k8s.io/v1
kind: MutatingWebhookConfiguration
metadata:
name: "valipod-policy.example.com"
webhooks:
- name: "valipod-policy.example.com"
rules:
- apiGroups: ["apps"]
apiVersions: ["v1"]
operations: ["CREATE"]
resources: ["deployments"]
scope: "Namespaced"
clientConfig:
url: "https://10.0.0.1:81/validate" # 在 cluster 外部的模式
# service:
# namespace: "default"
# name: "admission-webhook"
# port: 81
# path: "/mutate"
caBundle: "Ci0tLS0tQk...<base64-encoded PEM bundle containing the CA that signed the webhook's serving certificate>...tLS0K"
admissionReviewVersions: ["v1"]
sideEffects: None
timeoutSeconds: 5{
"kind": "AdmissionReview",
"apiVersion": "admission.k8s.io/v1",
"request": {
"uid": "705ab4c5-6393-11e8-b7cc-42010a800002",
"kind": {"group": "", "version": "v1", "kind": "Pod"},
"resource": {"group": "", "version": "v1", "resource": "pods"},
"namespace": "default",
"operation": "CREATE",
"userInfo": {
"username": "admin",
"uid": "014fbff9a07c",
"groups": ["system:authenticated", "my-admin-group"],
"extra": {
"some-key": ["some-value1", "some-value2"]
}
},
"object": {
"metadata": {
"name": "my-pod",
"namespace": "default",
"labels": {"app": "my-app"}
},
"spec": {
"containers": [
{
"name": "my-container",
"image": "my-image"
}
]
}
},
"oldObject": null,
"dryRun": false
}
}v1.30
ValidatingAdmissionPolicy和AdmissionWebhookMatchConditions進入 GA
用途
安全策略的實施
- 限制特權容器:防止在集群中運行具有特權的容器。可以使用
PodSecurityPolicy(雖然在 Kubernetes 1.25 開始被移除,但可以使用替代的 Open Policy Agent 或 Kyverno 等工具)來限制 Pod 運行特權模式。 - 阻止主機網路:阻止 Pod 使用主機網路或主機的 PID/IPC 命名空間,以增強隔離性。
- 強制映像簽名驗證:可以實施控制器來檢查容器映像是否有合法的簽名,確保只有信任的映像被部署。
資源配額和限制
- 配額管理:使用
ResourceQuota來限制命名空間中可用的資源總量,例如 CPU、記憶體、PersistentVolumeClaim的數量等。 - 資源請求限制:使用
LimitRange來設置 Pod 或容器的資源請求和限制範圍,避免單個 Pod 消耗過多資源。
合規性與政策強制
- 標籤和注釋檢查:強制要求 Pod、Service、Deployment 等資源包含特定的標籤或注釋,這在實施組織內部的標準化和合規性策略時非常有用。
- 命名規則強制:檢查和強制執行資源名稱的規則,確保名稱符合組織的命名慣例或政策。
網路策略控制
- 強制網路隔離:確保所有 Pod 必須遵循特定的網路策略,這樣可以防止未經允許的網路通信。
- 自動注入網路策略:在資源創建時自動注入預定義的網路策略,確保 Pod 在部署時即具有適當的網路隔離。
動態配置管理
- 自動注入 sidecar 容器:使用
MutatingAdmissionWebhook來自動注入 sidecar 容器(如 Istio 的 Envoy 代理或監控代理)到 Pod 中,這樣可以確保所有應用都遵守網路管理或監控要求。 - 配置文件注入:動態地將
ConfigMap或Secret注入到容器內,確保配置管理的靈活性和一致性。
策略執行與審計
- Pod 安全性策略(PodSecurityPolicy):雖然 PodSecurityPolicy 已被廢棄,但在 Kubernetes 1.25 之前,它被廣泛用於控制 Pod 的安全配置,如允許的卷類型、執行用戶、文件系統權限等。
- Pod 安全性標準(PodSecurity Standard):新的 Pod 安全性標準允許在命名空間級別配置安全級別(如 “restricted”, “baseline”, “privileged”),並通過 Admission Controller 強制執行。
資源自動標籤
- 環境標籤:自動將資源標記為
development,staging,production等,基於所部署的環境進行標識。 - 審計標籤:自動將創建者或時間戳等信息標記到資源中,便於後續審計和排查。
拒絕不安全或不符合政策的操作
- 阻止不允許的卷類型:防止 Pod 使用不允許的卷類型(如主機路徑卷),這可能會引發安全風險。
- 阻止使用不安全的映像版本:防止部署包含已知漏洞的容器映像。
版本控制
- 升級策略強制:防止不兼容的應用版本在不正確的 Kubernetes 版本中部署,以避免潛在的運行時問題。
自動化流程
- 自動填充配置:在資源創建過程中,根據標準模板自動填充必要的配置項目(如環境變數、卷掛載等)。
- 自動化測試:在資源創建或更新前,執行自動化測試或校驗腳本,確保資源符合預期。