Edit the configuration to point to the provided HTTPS endpoint correctly. Finally, test if the configuration is working by trying to deploy the vulnerable resource…

Question

Explanation

Kubernetes Admission Webhook Configuration - Exam Explanation

Overall Goal

This question tests your ability to configure a Kubernetes Admission Webhook (likely a ValidatingWebhookConfiguration or MutatingAdmissionWebhook) to point to an external HTTPS policy enforcement endpoint - such as OPA/Gatekeeper, Kyverno, or a custom admission controller. The final test confirms the webhook is actively intercepting and rejecting the vulnerable resource, proving enforcement is live.

Why This Approach Is Correct

Kubernetes admission controllers sit between the API server and etcd. When a resource is submitted, the API server calls the webhook's HTTPS endpoint before persisting the object. If the endpoint rejects it, the deploy fails - which is exactly the security goal.

Step-by-Step Breakdown

Step 1 - Locate and Edit the Webhook Configuration

kubectl edit validatingwebhookconfiguration <webhook-name>
# or edit the manifest directly and kubectl apply -f it

Why: The clientConfig.url or clientConfig.service field defines where the API server sends admission requests. If this points to the wrong endpoint (wrong host, port, or path), the API server either skips enforcement or throws a connection error.

What to fix: Update the url: field to the provided HTTPS endpoint exactly:

clientConfig:
  url: "https://<provided-endpoint>/validate"
  caBundle: <base64-encoded-CA>

Critical: The endpoint must be HTTPS. Kubernetes requires TLS for all webhook endpoints - HTTP will be rejected outright.

If skipped: The webhook either calls a dead endpoint (causing a timeout) or calls the wrong service, meaning no policies are enforced.

Step 2 - Verify caBundle Is Correct

The caBundle field must contain the base64-encoded CA certificate that signed the webhook server's TLS cert.

Why: The API server validates the webhook server's certificate against this CA. Without a matching caBundle, the TLS handshake fails and requests are either dropped or the webhook is bypassed (depending on failurePolicy).

If skipped: You'll get x509: certificate signed by unknown authority errors, and admission calls will fail silently if failurePolicy: Ignore.

Step 3 - Check failurePolicy

failurePolicy: Fail   # ← correct for security enforcement
# vs
failurePolicy: Ignore # ← silently skips on error

Why: Fail ensures that if the webhook is unreachable or errors out, the resource is blocked. Ignore means a misconfigured webhook lets everything through - a dangerous gap.

Step 4 - Test by Deploying the Vulnerable Resource

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

Why this is the validation step: If the webhook is correctly configured and the policy denies this resource, the kubectl apply should return an error like:

Error from server: admission webhook "..." denied the request: <policy reason>

What success looks like: The deploy is rejected. A successful apply here would mean the webhook isn't working.

If skipped: You have no proof the configuration is actually enforcing policy - the exam expects you to demonstrate it works, not just that it's configured.

What Goes Wrong If Steps Are Out of Order

Memory Tip

Think of it as "Point → Trust → Enforce → Prove":

• Point the webhook at the right HTTPS URL
• Trust is established via caBundle
• Enforce with failurePolicy: Fail
• Prove it works by attempting the vulnerable deploy and watching it get denied

The exam rewards the full loop - configuration alone is not enough; you must demonstrate the security control is actually blocking what it should.

No community discussion yet for this question.