介紹

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

https://kubernetes.io/images/blog/2019-03-21-a-guide-to-kubernetes-admission-controllers/admission-controller-phases.png

Admission Controller 主要分為兩種類型:Mutating Admission 和 Validating Admission。

Mutating Admission

在物件被儲存進 etcd 之前修改其屬性。例如,可以自動新增缺少的欄位或根據某些規則修改物件。

Validating Admission

驗證請求的合法性,確保請求符合集群的策略和安全規範。例如,禁止特定的映像或限制資源的使用。

內建的 Admission Controller

Admission Controllers Reference | Kubernetes

  • NamespaceLifecycle: 確保資源只能在有效的命名空間中創建
  • ResourceQuota: 強制執行資源配額的限制
  • LimitRanger: 強制執行 Pod 和 Container 的資源限制
  • ServiceAccount: 自動為 Pod 指派 ServiceAccount

自定義 Admission Webhook

  • 在 Kubernetes 上註冊一個 webhook config
    • 兩種 kind: ValidatingWebhookConfigurationMutatingWebhookConfiguration
  • 起一個 HTTP server 處理 api-server 的內容

範例

ValidatingWebhookConfiguration
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 的逾時時間
MutatingWebhookConfiguration
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
AdmissionReview
{
  "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 ValidatingAdmissionPolicyAdmissionWebhookMatchConditions 進入 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 中,這樣可以確保所有應用都遵守網路管理或監控要求。
  • 配置文件注入:動態地將 ConfigMapSecret 注入到容器內,確保配置管理的靈活性和一致性。

策略執行與審計

  • Pod 安全性策略(PodSecurityPolicy):雖然 PodSecurityPolicy 已被廢棄,但在 Kubernetes 1.25 之前,它被廣泛用於控制 Pod 的安全配置,如允許的卷類型、執行用戶、文件系統權限等。
  • Pod 安全性標準(PodSecurity Standard):新的 Pod 安全性標準允許在命名空間級別配置安全級別(如 “restricted”, “baseline”, “privileged”),並通過 Admission Controller 強制執行。

資源自動標籤

  • 環境標籤:自動將資源標記為 development, staging, production 等,基於所部署的環境進行標識。
  • 審計標籤:自動將創建者或時間戳等信息標記到資源中,便於後續審計和排查。

拒絕不安全或不符合政策的操作

  • 阻止不允許的卷類型:防止 Pod 使用不允許的卷類型(如主機路徑卷),這可能會引發安全風險。
  • 阻止使用不安全的映像版本:防止部署包含已知漏洞的容器映像。

版本控制

  • 升級策略強制:防止不兼容的應用版本在不正確的 Kubernetes 版本中部署,以避免潛在的運行時問題。

自動化流程

  • 自動填充配置:在資源創建過程中,根據標準模板自動填充必要的配置項目(如環境變數、卷掛載等)。
  • 自動化測試:在資源創建或更新前,執行自動化測試或校驗腳本,確保資源符合預期。

參考資料