Two more names worth knowing: Kyverno and kube-bench

Speaker notes

• Kyverno solves the same admission-control problem as the Gatekeeper covered on the previous slide, but without requiring Rego at all — a ClusterPolicy resource reads almost exactly like the Kubernetes resource it's validating. Its genuinely differentiating feature is mutate and generate support living in the same resource as validate: it can automatically inject a missing resource limit into a Deployment instead of only rejecting the deploy outright, which Gatekeeper handles far more awkwardly via separate, less mature CRDs.
• Be honest about the tradeoff, don't just sell Kyverno: Gatekeeper's Rego is a genuinely more portable choice when the same policy logic needs to run somewhere other than Kubernetes too — gating a Terraform plan, or a raw API call, using the exact same rule engine. Kyverno's YAML-native model is Kubernetes-only by design.
• kube-bench is a completely different kind of tool — not admission control, but an auditor, checking a running cluster against the named CIS Kubernetes Benchmark, the same discipline Docker Bench applied to a single Docker host two slides ago.
• The callback that makes this slide worth including: kube-bench's control-plane checks assume you actually manage a control plane. On a self-managed cluster, you own every one of those findings. On EKS, GKE, or AKS, the cloud provider runs that control plane entirely — those specific checks are structurally the provider's job, not yours. This is Module 1's shared responsibility model, made concrete for exactly one technology, and it's worth pausing on: knowing which findings are actually actionable on your specific cluster type is the real skill, not just running the tool.

Deck map