02 - Validating and Mutating Admission Controllers

Validating and Mutating Admission Controllers


🔧 Mutating Admission Controller（變更型）

✅ 功能：

  • 修改用戶提交的資源物件
  • 常用於補上預設值、標籤、或注入 Sidecar

📌 實際用途：

  • 自動加入監控 sidecar（如 Istio、Datadog）
  • 補上預設 labels 或 annotations
  • 加入預設的資源限制（CPU/記憶體）
  • 加上 Tolerations、Node Affinity 等

🧩 常見元件：

  • MutatingAdmissionWebhook
  • MutatingAdmissionPolicy（Kubernetes 1.28+ GA）


🔍 Validating Admission Controller（驗證型）

✅ 功能：

  • 驗證資源是否合法，若不符合條件則拒絕執行
  • 無法修改資源，只能判斷通過或拒絕

📌 實際用途：

  • 拒絕使用 latest image tag
  • 禁止容器使用 root 權限
  • 限制只能使用特定的 StorageClass
  • 確保所有物件都有必要的 label

🧩 常見元件：

  • ValidatingAdmissionWebhook
  • ValidatingAdmissionPolicy（Kubernetes 1.28+ GA）


執行順序（流程圖）

1️⃣ 使用者發送 API 請求
     ↓
2️⃣ 驗證身份與權限（Authentication / Authorization）
     ↓
3️⃣ Mutating Admission Controller（如需修改）
     ↓
4️⃣ Validating Admission Controller（檢查是否合法）
     ↓
5️⃣ 通過後寫入 etcd，開始執行

Q: Which of the below combination is correct for Mutating and validating admission controllers ?

Ans: NamespaceAutoProvision - Mutating, NamespaceExists - Validating


Q: What is the flow of invocation of admission controllers?

Ans: First Mutating then Validating


連續題組

Q: Create namespace `webhook-demo` where we will deploy webhook components

$ kubectl create ns webhook-demo            

$ kubectl get ns                                       


Q: Create TLS secret `webhook-server-tls` for secure webhook communication in `webhook-demo` namespace.

We have already created below cert and key for webhook server which should be used to create secret.

  • Certificate : /root/keys/webhook-server-tls.crt
  • Key : /root/keys/webhook-server-tls.key

Create `tls` secret type in kubernetes with `--cert` and `--key` options

$ kubectl -n webhook-demo create secret tls webhook-server-tls \
--cert /root/keys/webhook-server-tls.crt             \
--key /root/keys/webhook-server-tls.key              

Q: Create webhook deployment now.

$ kubectl create -f /root/webhook-deployment.yaml       
or
$ kubectl apply -f /root/webhook-deployment.yaml        

vim /root/webhook-deployment.yaml

Q: Create webhook service now so that admission controller can communicate with webhook.

$ kubectl create -f /root/webhook-service.yaml         
or
$ kubectl apply -f /root/webhook-service.yaml          

vim /root/webhook-service.yaml

Q: We have added MutatingWebhookConfiguration under /root/webhook-configuration.yaml.

If we apply this configuration which resource and actions it will affect?
Ans: Pod with CREATE operations

$ cat /root/webhook-configuration.yaml                

cat /root/webhook-configuration.yaml

vim /root/webhook-configuration.yaml

Q: Now lets deploy MutatingWebhookConfiguration in /root/webhook-configuration.yaml

$ kubectl create -f /root/webhook-configuration.yaml            

連續題組

In previous steps we have deployed demo webhook which does below

- Denies all request for pod to run as root in container if no securityContext is provided.

- If no value is set for runAsNonRoot, a default of `true` is applied, and the user ID defaults to `1234`

- Allow to run containers as root if runAsNonRoot set explicitly to `false` in the securityContext

In next steps we have added some pod definitions file for each scenario. Deploy those pods with existing definitions file and validate the behaviour of our webhook


Q: Deploy a pod with no securityContext specified.

We have added pod definition file under `/root/pod-with-defaults.yaml`

$ kubectl apply -f /root/pod-with-defaults.yaml         

vim /root/pod-with-defaults.yaml

Q: 【承上題】 What are `runAsNonRoot` and `runAsUser` values for previously created pods securityContext?

  • We did not specify any `securityContext` values in pod definition so check out the changes done by mutation webhook in pod
Ans: runAsNonRoot: true, runAsUser: 1234

$ kubectl get pod pod-with-defaults -o yaml | grep -i securityContext -A 2          

Check securityContext fields in created pod yaml.
(runAsNonRoot)

Q: Deploy pod with a securityContext explicitly allowing it to run as root

  • We have added pod definition file under `/root/pod-with-override.yaml`
cat /root/pod-with-override.yaml
(runAsRoot)

$ kubectl apply -f /root/pod-with-override.yaml                                          
$ kubectl get po pod-with-override -o yaml | grep -A2 " securityContext:"      

Validate securityContext after you deploy this pod
(runAsRoot)

Q: Deploy a pod with a conflicting securityContext i.e. pod running with a user id of 0 (root)

  • We have added pod definition file under `/root/pod-with-conflict.yaml`
cat /root/pod-with-conflict.yaml
(runAsNonRoot <-> root)

Mutating webhook should reject the request as its asking to run as root user without setting `runAsNonRoot: false`

You should get error like this.

🚫 問題點：

  • runAsNonRoot: true → 表示此容器不能以 root 身份執行
  • runAsUser: 0 → 但這裡卻指定了 UID 0（即 root）


留言

張貼留言