Luca BertonPolicy Enforcement: Where Compliance Meets Kubernetes
In regulated enterprises, it's not enough to document security policies — you need to enforce them automatically. OPA Gatekeeper is a Kubernetes admission controller that rejects non-compliant resources before they're created. If a developer tries to deploy a container running as root, without resource limits, or from an untrusted registry — Gatekeeper blocks it.
How Gatekeeper Works
Gatekeeper intercepts Kubernetes API requests as a validating admission webhook:
- Developer creates a Pod/Deployment (kubectl apply or GitOps)
- Kubernetes API server sends the request to Gatekeeper before storing it
- Gatekeeper evaluates the request against defined policies (ConstraintTemplates)
- If the request violates a policy → rejected with a clear error message
- If the request passes all policies → allowed to proceed
Key distinction: Gatekeeper is preventive, not detective. It stops non-compliant resources from being created rather than finding them after the fact.
Essential Policies for Regulated Environments
Security Policies
- No privileged containers — Block containers running with
privileged: true - No root users — Require
runAsNonRoot: trueon all containers - Read-only root filesystem — Enforce
readOnlyRootFilesystem: truewhere possible - No host networking/PID/IPC — Block pods that share host namespaces
- Drop all capabilities — Require explicit capability additions, deny ALL by default
- Image allowlisting — Only allow images from approved registries (e.g., your private ECR/ACR/GCR)
- No latest tag — Require specific image tags or digests for reproducibility
Resource Management Policies
- Required resource requests/limits — Every container must specify CPU and memory requests and limits
- Maximum resource limits — Prevent any single pod from consuming excessive cluster resources
- Required labels — Enforce team, project, and cost-centre labels for cost allocation and audit
- Required probes — Mandate liveness and readiness probes on all production workloads
Compliance-Specific Policies
- DORA — Audit logging: Require sidecar or annotation for audit log collection on critical workloads
- NIS2 — Encryption: Block services without TLS termination (Istio mTLS or Ingress TLS required)
- GDPR — Data residency: Restrict nodeSelector/affinity to approved regions for workloads processing personal data
- CRA — SBOM: Require image annotations containing SBOM references
Kubernetes Recipes
Practical guide for container orchestration and deployment — hands-on patterns you can use today.
View on Amazon →Gatekeeper vs Kyverno
| Aspect | Gatekeeper (OPA) | Kyverno |
|---|---|---|
| Policy language | Rego (OPA's policy language) | YAML (Kubernetes-native) |
| Learning curve | Steeper (Rego is a new language) | Lower (YAML-based policies) |
| Mutation | Supported (mutation webhooks) | First-class (mutate + validate) |
| Generation | Limited | Can generate resources (NetworkPolicies, etc.) |
| Ecosystem | OPA is used beyond K8s (API gateways, CI/CD) | Kubernetes-only |
Choose Gatekeeper if: You want OPA's broader ecosystem (use same policies in CI/CD, API gateways, Terraform). Choose Kyverno if: You want simpler YAML-based policies and resource generation capabilities.
Implementation Roadmap
- Week 1: Install Gatekeeper in audit mode (dryrun) — policies log violations but don't block
- Week 2: Deploy the Gatekeeper library's standard policies (no privileged, no root, resource limits)
- Week 3: Review violations, work with teams to remediate existing non-compliant resources
- Week 4: Switch critical policies to enforcement mode (deny). Keep less critical policies in audit.
- Ongoing: Add custom policies for your regulatory requirements, integrate with CI/CD for shift-left validation.
Evaluating RAG Solutions
Choose the right RAG model, configure, test, and optimise.
Start on Pluralsight →