How would you use a Kubernetes Admission Controller as CI/CD security gate?

WHAT THIS TESTS: This question probes whether you understand the Kubernetes admission chain as a preventive control point rather than a detective one. Interviewers want to see that you know admission controllers intercept requests after authentication and authorization but before objects persist to etcd, making them ideal for CI/CD security gates. They are checking for familiarity with both built-in and dynamic admission controllers, and whether you can articulate specific policies that should be enforced at deployment time rather than deferred to runtime.

A GOOD ANSWER COVERS: First, distinguish between built-in admission plugins like Pod Security Admission and dynamic webhooks such as ValidatingAdmissionWebhook or MutatingAdmissionWebhook. Second, explain that in a CI/CD context you typically rely on validating webhooks to reject non-compliant manifests before they are scheduled, while mutating webhooks can auto-inject sidecars or defaults. Third, list concrete policies: enforce Pod Security Standards at the restricted level to prevent privileged containers, root users, and host namespace sharing; require resource requests and limits to prevent noisy neighbor attacks; enforce image pull policies and prohibit latest tags; verify image signatures with admission plugins like Cosign or Ratify; mandate labels and annotations for cost allocation and ownership; and block the use of default service accounts or mounted service account tokens when unnecessary. Fourth, mention that these policies should be versioned and tested in CI before being promoted to the cluster, and that dry-run modes help prevent production outages.

COMMON WRONG ANSWERS: Confusing admission controllers with RBAC is a major red flag; RBAC decides who can create a resource, while admission decides whether the resource is allowed to exist. Another mistake is suggesting that security scanning should only happen at runtime or in the image registry; the interviewer wants deployment-time enforcement. Proposing only mutating webhooks without validating ones can also signal shallow knowledge, as mutating alone does not block intentionally malicious manifests. Finally, ignoring Pod Security Admission entirely and jumping straight to third-party tools suggests you are not up to date with recent Kubernetes releases.

LIKELY FOLLOW-UPS: How do you handle admission webhook failures when the webhook endpoint is down? What is the performance impact of adding multiple validating webhooks to the API server path? How would you safely roll out a new policy without breaking existing deployments? Can you explain the difference between Pod Security Policies and Pod Security Admission? How do you integrate image signature verification into the admission flow without slowing down deployments?

ONE CONCRETE EXAMPLE: Suppose your pipeline deploys a microservice that accidentally requests privileged mode and uses an image tagged latest. A ValidatingAdmissionWebhook backed by Kyverno or OPA Gatekeeper intercepts the Deployment creation request. It checks the Pod template against your cluster policies: the privileged flag violates the restricted Pod Security Standard, and the latest tag violates your image policy. The API server rejects the request with a clear error message that surfaces back to the CI/CD job, failing the deployment before any Pod is scheduled. The developer receives immediate feedback and must push a compliant manifest to proceed.

Source: kubernetes.io