Courses Kubernetes attack & defenseAdmission control internals

PSA, Kyverno & Gatekeeper

The pod-hardening floor plus custom policy.

Advanced30 min · lesson 8 of 15

With the admission pipeline understood, the question is which policy engine enforces what. Pod Security Admission covers the built-in pod-hardening baseline; Kyverno and Gatekeeper cover everything custom. Used together they form a defense-in-depth admission layer.

Pod Security Admission

PSA is the built-in successor to the removed PodSecurityPolicy. It enforces the Pod Security Standards — three profiles applied per namespace via labels: privileged (no restrictions), baseline (blocks the most dangerous settings), and restricted (the hardened profile: runAsNonRoot, no privilege escalation, drop ALL capabilities, seccomp RuntimeDefault, no hostPath/hostNetwork). Each profile runs in one of three modes — enforce (reject), audit (log), warn (message) — so you can roll out by labeling namespaces audit/warn first, then enforce. PSA is the cheapest, highest-value admission control you can turn on.

enforce restricted with a rollout path

# Label a namespace to enforce "restricted" — and warn on the next standard up,
# so you see what a stricter policy would catch before flipping it to enforce.
apiVersion: v1
kind: Namespace
metadata:
  name: prod
  labels:
    pod-security.kubernetes.io/enforce: restricted
    pod-security.kubernetes.io/enforce-version: latest
    pod-security.kubernetes.io/warn: restricted
    pod-security.kubernetes.io/audit: restricted
# Non-compliant pods (privileged, hostPath, root) are now rejected in prod.

Custom policy with Kyverno / Gatekeeper

PSA governs the pod security context but cannot express arbitrary rules — for that you add a policy engine. Kyverno uses declarative YAML policies (validate, mutate, generate, verifyImages); OPA Gatekeeper uses Rego constraints. They enforce the things PSA cannot: only signed images from your registry may run, every pod must carry certain labels, no LoadBalancer services in this namespace, inject a default network policy. The pattern for both is the same as everywhere: author policy as reviewed, version-controlled code, roll it out in audit before enforce, and treat exceptions as scoped and expiring.

Layered admission policy

built-in baseline

Pod Security Admission

privileged/baseline/restricted

enforce / audit / warn

per-namespace rollout

custom rules

Kyverno (YAML)

validate/mutate/verifyImages

Gatekeeper (Rego)

constraint templates

PSA for the pod-hardening floor, a policy engine for everything else. Author as code, roll out audit→enforce, scope exceptions.

A cluster with no admission policy trusts every workload

Without PSA (at least baseline) and a policy engine, any subject who can create a pod can create a privileged one, mount the host, or run an unsigned image. Enable Pod Security Admission on every namespace and add a policy engine for signatures and custom rules — admission is not optional in a hardened cluster.

Admission control internalsWebhook security & bypasses