How would you use a Kubernetes Admission Controller as CI/CD security gate?
Tests pre-deployment enforcement via admission webhooks. Strong answers: ValidatingAdmissionWebhooks blocking bad manifests, Pod Security Standards restricted profiles, and OPA/Gatekeeper for image signatures. Red flag: confusing with RBAC or runtime scanning.
What's really being asked
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.
The full answer
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.
The mistakes people make
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.
What usually comes next
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?
A 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.
Interview question
You need to block privileged containers from reaching the cluster through your deployment pipeline. Which approach correctly applies Kubernetes admission controls as a preventive gate?
- a.Scan running containers with a runtime security tool to detect privilege escalations after deployment, using admission controllers only for audit logging.
- b.Configure a MutatingAdmissionWebhook to remove privileged flags from incoming Pod specs, avoiding the need for explicit deployment-time rejection.
- c.Apply Pod Security Admission with the restricted profile and use a ValidatingAdmissionWebhook to reject violating manifests before they persist to etcd.Correct
- d.Rely on RBAC to limit which service accounts can create Pods, since RBAC also evaluates manifest contents before persistence.
Why? this is the answer
Pod Security Admission at the restricted level and a ValidatingAdmissionWebhook enforce policy before objects reach etcd, serving as a true preventive gate. Relying solely on a MutatingAdmissionWebhook is dangerous because it does not block intentionally malicious manifests and can silently violate security intent.
Just read this? Test yourself on what you have been reading.
Read the original → kubernetes.io
- #kubernetes
- #security
- #cicd
- #admission controllers
- #devops
You just looked this up. Could you explain it out loud?
That is the part interviews actually test. Tezvyn takes questions like this one and gives you what the interviewer is really checking, the answer that lands, and the mistake that ends the conversation, in the four minutes before your next meeting.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Open roles that interview on kubernetes — each one lists the topics its interview covers.
See open roles