Security is increasingly the differentiator between mid-level and senior Kubernetes roles. As organizations move production workloads to Kubernetes, they need engineers who can harden clusters rather than just deploy to them.
Interviewers test security knowledge across multiple layers. Foundational questions cover security contexts ("How do you ensure a container runs as non-root?") and Pod Security Standards ("What happens when you apply the Restricted profile to a namespace?"). Intermediate questions address admission controllers — both built-in (like PodSecurity) and external (like OPA Gatekeeper or Kyverno) — and how they enforce policy.
Advanced interviews explore the full API request lifecycle: how a kubectl command is authenticated (certificates, tokens, OIDC), authorized (RBAC), and then validated or mutated by admission webhooks. Candidates targeting CKS certification should also be ready to discuss supply chain security, runtime threat detection, and audit logging.
Demonstrating a layered, defense-in-depth approach to security shows interviewers that you think about cluster protection systematically rather than relying on any single control.
Kubernetes Secrets store sensitive data like passwords, tokens, and keys. By default they are only base64-encoded, not encrypted. Best practices include enabling encryption at rest, using external secret managers, limiting RBAC access, and avoiding storing Secrets in Git.
Pod Security Standards define three levels of security policies (Privileged, Baseline, Restricted) enforced by the built-in Pod Security Admission controller. They replace the deprecated PodSecurityPolicy and are applied at the namespace level using labels.
Security contexts define privilege and access control settings for Pods and containers. They control the user and group IDs a process runs as, whether privilege escalation is allowed, Linux capabilities, read-only root filesystems, and seccomp/AppArmor profiles.
Admission controllers are plugins that intercept API requests after authentication and authorization but before the object is persisted to etcd. They can validate or mutate requests. Kubernetes includes many built-in controllers, and you can add custom ones via webhooks.
The API server authenticates requests using a chain of authenticators: client certificates (X.509), bearer tokens (ServiceAccount, OIDC), webhook token authentication, and anonymous access. The first authenticator that accepts the request determines the identity. After authentication, authorization (RBAC) decides what the identity can do.