Hardening Kubernetes Admission Control: Real-World Policies and Enforcement

Kubernetes is the backbone of modern cloud-native infrastructure, but its flexibility is a double-edged sword: misconfigurations and insecure defaults can expose your entire platform. Hardening your cluster with robust admission control is no longer optional—it's essential for production workloads in 2024.

What Is Kubernetes Admission Control and Why Does It Matter?

Admission controllers in Kubernetes are plugins that intercept API requests before they persist in etcd, allowing you to enforce security, compliance, and operational policies cluster-wide. Unlike RBAC, which controls who can perform actions, admission controllers focus on what can be deployed or changed, examining and modifying resources before they're admitted.

The most effective admission control approaches leverage policy-as-code engines like OPA Gatekeeper (v3.13+), Kyverno (v1.10+), or Kubernetes-native admission webhooks. These allow you to codify best practices—like blocking privileged containers, enforcing image registries, or requiring resource limits—at scale.

Here's a sample OPA Gatekeeper ConstraintTemplate (YAML) that blocks privileged pods:

apiVersion: templates.gatekeeper.sh/v1beta1
kind: ConstraintTemplate
metadata:
  name: k8srequiredlabels
spec:
  crd:
    spec:
      names:
        kind: K8sNoPrivilegedContainers
  targets:
    - target: admission.k8s.gatekeeper.sh
      rego: |
        package k8srequiredlabels
        violation[{
          "msg": msg,
          "details": {"container": container.name}
        }] {
          container := input.review.object.spec.containers[_]
          container.securityContext.privileged == true
          msg := sprintf("Privileged container '%s' is not allowed", [container.name])
        }

Key insight: Admission controllers empower you to codify and enforce cluster-wide security and compliance controls that can't be bypassed by developers or CI/CD pipelines.

1. How to Select the Right Admission Controller for Your Use Case

Understand Built-in vs. External Controllers

Kubernetes offers both built-in admission controllers (like NamespaceLifecycle, PodSecurity) and external webhooks (like OPA Gatekeeper, Kyverno, or custom Go services). Built-ins are simple but limited; webhooks offer extensibility and policy-as-code support.

Evaluate Policy Complexity and Ecosystem Support

If you need advanced, reusable, or organization-wide policies, lean towards OPA Gatekeeper or Kyverno. Gatekeeper is well-suited for complex logic using Rego, while Kyverno uses more approachable YAML-based syntax and is native to Kubernetes CRDs.

Consider Deployment Footprint and Cloud Integration

Gatekeeper and Kyverno both run as pods and scale well. However, Gatekeeper is more widely integrated with cloud security dashboards (AKS Defender, GKE Security Posture, etc.). Kyverno integrates smoothly with GitOps and Kustomize pipelines thanks to its native resource mutation features.

Security and Performance Benchmarks

OPA Gatekeeper (v3.13+) adds support for native CEL policies, drastically reducing latency for common patterns (sub-20ms for most requests). Kyverno (v1.10+) offers benchmarks of <30ms per request under typical load. Both tools support horizontal scaling and policy audit modes for performance tuning.

Key insight: Choose Gatekeeper for advanced logic and enterprise integrations; Kyverno for Kubernetes-native syntax and rapid onboarding.

2. Step-by-Step: Deploying OPA Gatekeeper in Production

1. Install Gatekeeper Using Helm

I recommend using the official Gatekeeper Helm chart for repeatable, version-pinned installs:

helm repo add gatekeeper https://open-policy-agent.github.io/gatekeeper/charts
git checkout v3.13.0
helm install gatekeeper/gatekeeper --name-template gatekeeper --namespace gatekeeper-system --create-namespace

2. Define and Apply ConstraintTemplates

Create a file no-privileged-containers.yaml with the ConstraintTemplate from above, then apply it:

kubectl apply -f no-privileged-containers.yaml

3. Bind Policies with Constraints

Bind the template to namespaces or clusters via a Constraint resource:

apiVersion: constraints.gatekeeper.sh/v1beta1
kind: K8sNoPrivilegedContainers
metadata:
  name: no-privileged
spec:
  match:
    kinds:
      - apiGroups: [""]
        kinds: ["Pod"]

4. Test and Monitor Enforcement

Attempt to deploy a privileged pod. Gatekeeper should block it with a clear error. Monitor violations using:

kubectl get constrainttemplates
kubectl get constraints

5. Integrate with CI/CD

Add a manifest validation step in your CI pipeline using conftest or OPA CLI, ensuring policies are enforced before hitting the cluster.

Key insight: Automate policy deployment and validation in CI/CD to eliminate drift between code, manifests, and runtime enforcement.

3. Enforcing Common Security Policies with Kyverno

1. Install Kyverno via Helm or Static Manifests

For production, always pin Kyverno to a tested version (e.g., v1.10.0) and install in its own namespace:

helm repo add kyverno https://kyverno.github.io/kyverno/
helm install kyverno/kyverno --namespace kyverno --version 1.10.0 --create-namespace

2. Enforce Image Registry Restrictions

Block images not sourced from trusted internal registries:

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: require-trusted-image-registry
spec:
  validationFailureAction: Enforce
  rules:
  - name: check-image-registry
    match:
      resources:
        kinds:
        - Pod
    validate:
      message: "Images must be from 'registry.mycorp.com'"
      pattern:
        spec:
          containers:
          - image: "registry.mycorp.com/*"

3. Require Resource Limits

Use a Kyverno policy to block pods missing CPU/memory resource limits:

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: require-resource-limits
spec:
  validationFailureAction: Enforce
  background: true
  rules:
  - name: check-resource-limits
    match:
      resources:
        kinds:
        - Pod
    validate:
      message: "CPU and memory limits are required."
      pattern:
        spec:
          containers:
          - resources:
              limits:
                cpu: "*"
                memory: "*"

4. Audit and Remediate Non-Compliant Resources

Kyverno can auto-remediate existing resources with its mutate and generate features (e.g., adding default labels or limits). Use kyverno apply to test policies against manifests before applying.

Key insight: Kyverno's YAML-first approach enables rapid policy authoring and real-time enforcement for security and compliance at scale.

4. Scaling Admission Control in Multi-Cluster Environments

1. Centralized Policy Management with GitOps

For organizations running dozens of clusters, centralize policy definitions in a Git repository. Use ArgoCD or FluxCD to sync policies to all clusters automatically.

2. Policy Versioning and Promotion

Adopt semantic versioning for policy bundles. Test policies in lower environments before promoting to production. Use Open Policy Agent's Bundles or Kyverno policy sets for grouping.

3. Cluster-Specific Overrides

Leverage policy exceptions or matching rules for cluster-specific needs (e.g., different allowed registries in dev vs. prod). OPA and Kyverno both support namespace and label-based targeting.

4. Monitoring and Alerting

Integrate policy violation events with Prometheus, Grafana, or SIEM tools via Gatekeeper’s audit logs or Kyverno's policy report CRDs. Set up alerts for repeated or critical violations.

5. Policy Drift Detection

Regularly scan clusters for policy drift using Conftest, OPA CLI, or Kyverno's CLI tools, and remediate discrepancies automatically.

Key insight: Treat policies as code—automate their deployment, versioning, and monitoring across all clusters to prevent drift and ensure compliance.

5. Comparison Table: Gatekeeper vs. Kyverno vs. Native Webhooks

Feature/Tool	OPA Gatekeeper (v3.13+)	Kyverno (v1.10+)	Native Admission Webhook
Policy Language	Rego, CEL (v3.13+)	YAML/JSON	Go/any HTTP backend
Ease of Authoring	Medium (learning curve)	High (YAML-first)	Low (custom code)
Mutation Support	Limited (beta, v3.13+)	Full (mutate/generate)	Full
Cloud Integration	AKS Defender, GKE Security	ArgoCD, GitOps	None
Performance	15-30ms per request	20-40ms per request	Varies (10-50ms+)
Community Policies	Large (CNCF, enterprise)	Growing (CNCF, security)	None
Best Use Case	Complex org-wide policies	Fast YAML onboarding	Custom logic

Key insight: OPA Gatekeeper and Kyverno are both production-proven, but Kyverno offers faster onboarding while Gatekeeper excels in logic-heavy, enterprise scenarios.

Frequently Asked Questions

Q: What is the difference between a Kubernetes admission controller and RBAC? A: RBAC controls who can perform actions on resources. Admission controllers enforce what resources can be created, updated, or deleted, adding a layer of policy enforcement after authentication and authorization.

Q: Can I use multiple admission controllers together in production? A: Yes, it's common to combine built-in controllers (like PodSecurity) with external policy engines like OPA Gatekeeper or Kyverno. Order of execution matters—always test for conflicts and measure latency.

Q: How do I audit existing resources for policy compliance? A: Both OPA Gatekeeper and Kyverno support audit modes. You can run periodic scans or one-off audits using their CLI tools, and output results to Prometheus, SIEMs, or dashboards for remediation tracking.

Key Takeaways

• Deploy OPA Gatekeeper or Kyverno to enforce security policies across your Kubernetes clusters—don't rely on RBAC alone.
• Use policy-as-code to block privileged containers, enforce image provenance, and require resource limits in production.
• Integrate admission control policy validation into CI/CD pipelines to catch misconfigurations before deployment.
• Centralize policy management with GitOps tools like ArgoCD or FluxCD for multi-cluster consistency and drift prevention.
• Monitor for policy violations and connect audit logs to your SIEM or observability stack for real-time alerting.
• Regularly update and version admission control policies to address new attack vectors and evolving compliance needs.