Edit the configuration to point to the provided HTTPS endpoint correctly. You can find the container image scanner's log file at /var/log/imagepolicy/acme.log. Finally, test if the configuration is…

Question

Explanation

Kubernetes ImagePolicyWebhook Configuration - Exam Explanation

Overall Goal

This question tests your ability to configure Kubernetes' ImagePolicyWebhook admission controller, which intercepts pod creation requests and forwards image details to an external scanner (like Acme) over HTTPS. If the scanner deems an image vulnerable, the deployment is rejected. The exam validates both correct configuration and operational verification.

Background: How ImagePolicyWebhook Works

kubectl apply → API Server → ImagePolicyWebhook Admission Controller
                                        ↓ HTTPS POST
                               External Image Scanner
                                        ↓ allow/deny
                              Response back to API Server

The webhook is configured via two layered files:

1. Admission Configuration file - tells the API server which plugins are active and where their config lives
2. Webhook kubeconfig file - contains the actual HTTPS endpoint URL and TLS credentials for the scanner

Step-by-Step Breakdown

Step 1: Locate the API Server Manifest and Admission Config

cat /etc/kubernetes/manifests/kube-apiserver.yaml

Look for two flags:

• --enable-admission-plugins=...,ImagePolicyWebhook,...
• --admission-control-config-file=/path/to/admission-config.json

Why this matters: Without ImagePolicyWebhook in the enabled plugins list, the webhook is never invoked regardless of any other config. The config file path tells you where to look next.

If skipped: You'd edit the wrong file or never find the webhook kubeconfig.

Step 2: Inspect and Edit the Admission Configuration

The admission config (e.g., /etc/kubernetes/policies/admission-config.yaml) looks like:

apiVersion: apiserver.config.k8s.io/v1
kind: AdmissionConfiguration
plugins:
  - name: ImagePolicyWebhook
    configuration:
      imagePolicy:
        kubeConfigFile: /etc/kubernetes/policies/webhook-kubeconfig.yaml
        allowTTL: 50
        denyTTL: 50
        retryBackoff: 500
        defaultAllow: false   # deny if webhook unreachable

This file points to the webhook kubeconfig, which is what you actually edit.

Step 3: Edit the Webhook Kubeconfig to Point to the HTTPS Endpoint

# /etc/kubernetes/policies/webhook-kubeconfig.yaml
apiVersion: v1
kind: Config
clusters:
  - name: image-scanner
    cluster:
      server: https://<CORRECT-ENDPOINT>:<PORT>   # ← edit this
      certificate-authority: /path/to/ca.crt
users:
  - name: api-server
    user:
      client-certificate: /path/to/client.crt
      client-key: /path/to/client.key
contexts:
  - context:
      cluster: image-scanner
      user: api-server
    name: image-scanner
current-context: image-scanner

Why this matters: This is the actual network destination the API server POSTs image review requests to. An incorrect URL means either:

• Connection refused → falls back to defaultAllow (unsafe if false, pods stuck if true)
• TLS errors → same fallback behavior

If skipped or wrong: The scanner never receives requests. Vulnerable images get allowed or all deployments fail, depending on defaultAllow.

Step 4: Restart the API Server (Happens Automatically with Static Pods)

Since kube-apiserver is a static pod managed by kubelet, saving changes to /etc/kubernetes/manifests/kube-apiserver.yaml triggers an automatic restart. If you only edited the kubeconfig/admission config (not the manifest), you may need to touch the manifest to force a reload:

# Force static pod restart by touching the manifest
touch /etc/kubernetes/manifests/kube-apiserver.yaml

Why this matters: The API server reads its config at startup. In-flight changes to referenced files don't take effect until restart.

If skipped: Your edits have no effect; the old broken endpoint remains active.

Step 5: Verify via the Log File

tail -f /var/log/imagepolicy/acme.log

Look for entries showing the scanner receiving requests. A successful configuration produces log lines for each image review attempt.

Why this matters: The log confirms the scanner side is receiving traffic, ruling out a silent misconfiguration where the webhook accepts but ignores requests.

If skipped: You'd attempt the test blind - if it fails, you won't know whether the problem is the config, the endpoint, or the resource itself.

Step 6: Deploy the Vulnerable Resource

kubectl apply -f /root/KSSC00202/vulnerable-resource.yml

Expected outcome: The deployment is rejected with an error referencing the image policy, e.g.:

Error from server: pods "..." is forbidden: image policy webhook backend denied one or more images

Why this matters: This is the acceptance test - it proves the full chain (API server → webhook → scanner → deny decision) is working end-to-end. A successful kubectl apply here would mean the scanner is not blocking, indicating a misconfiguration.

If the deploy succeeds instead of failing: Check defaultAllow: true in admission config (should be false), verify the HTTPS endpoint is reachable, and re-check the log file.

What Goes Wrong Out of Order

Memory Tip

Think "PACER":

• Plugin - confirm ImagePolicyWebhook is enabled in the API server
• Admission config - find and read the admission config file
• Config endpoint - edit the kubeconfig with the correct HTTPS URL
• Ensure restart - let the static pod reload
• Run the test - deploy the vulnerable resource and confirm denial

The flow is always: enable → configure → restart → verify logs → test deny.

No community discussion yet for this question.