Share this post
Every Kubernetes cluster makes the same decision, thousands of times a day: whether an incoming pod, deployment, or namespace change is safe to accept. Applying this decision consistently on a single cluster is pretty straightforward, but enforcing it across dozens or hundreds of clusters, without drift or exemptions, is a challenge for many platform teams.
This is exactly the problem Portainer’s operator control plane is built to solve: pod security constraints, admission rules, and OPA Gatekeeper policies applied uniformly across every cluster it manages.
This guide covers how Kubernetes policy enforcement works, why manual approaches break down as clusters multiply, and how Portainer keeps every cluster in your fleet under the same set of rules.
What Is Kubernetes Policy Enforcement?
Kubernetes policy enforcement is the automated process of checking every workload and configuration change against a defined set of rules and blocking anything that violates them.
The rules cover the categories you would expect:
- Which container images and registries are allowed?
- Which security contexts and privileges can a workload request?
- Which labels and annotations must be present?
- Resource quotas per namespace
- Which teams can deploy where?
It’s important to note that policy enforcement differs from Kubernetes’ native access control.
RBAC determines who can create a resource but doesn’t verify whether the resource itself meets organizational security or compliance requirements. A developer with permission to deploy into their namespace can still submit a manifest that requests root privileges or pulls from an untrusted registry, and RBAC will let the request through.
Policy enforcement is the layer that catches these before they reach production, which is why it sits at the heart of most serious Kubernetes security programs.
What Kubernetes Policy Enforcement Helps You Achieve
Once enforcement is running properly across the fleet, here are a few things the platform teams can expect to see:
1. Automated Compliance for Audit and Regulatory Requirements
Compliance programs collapse under their own weight when they must manually prove that every production workload meets internal security policies and controls for PCI-DSS, HIPAA, GDPR, or SOC 2.
Rules encoded in Kyverno, OPA Gatekeeper, or Pod Security Admission generate an auditable record of every request the enforcement layer evaluates, providing auditors with direct evidence rather than roughly assembled screenshots. Here are a few artifacts an auditor can query:
- Admission decisions per workload, with the policy that evaluated the request and the outcome (allowed, mutated, or denied).
- Blocked-request logs showing which manifests violated policy, when, and from which team or pipeline.
- Policy version history tracking every change to the rule set and who approved it.
Non-compliant workloads never reach a running state, eliminating the class of audit findings in which a policy exists on paper but is violated in production.
2. Consistent Policy Across Every Cluster You Run
Enforcement declared as code and applied through a shared control plane produces the same admission decision on every cluster in the fleet, whether that’s a managed service in AWS, an on-prem Kubernetes deployment, or an edge site behind a firewall.
For teams running multi-cluster Kubernetes, this means writing and versioning the policy once, propagating it from a single commit, and having new clusters governed by the current rule set the moment they come online.
3. Security Without Slowing Down Delivery
Manual review of every deployment and policy exception creates friction. When it gets bad enough, developers simply stop asking for approval on borderline manifests, and platform teams stop being consulted before workloads reach production, which is worse than either extreme.
Automated policy enforcement removes the human from the loop for common cases. A manifest that meets policy is admitted without review at API-server latency, but one that violates it fails immediately with a specific error the developer can fix on their own.
Platform teams focus on genuinely novel requests, and developers stop treating security as the reason their releases are late.
Why Manual Policy Enforcement Fails Platform Teams
If you’re thinking of enforcing policy manually across your Kubernetes environment, here’s what breaks, especially as clusters, teams, and releases multiply:
1. Policy Drift Across Clusters
One of the most common failure modes of manual enforcement is policy drift: the same rule enforced differently across clusters, or enforced on some and skipped on others, without anyone tracking it.
It starts small but compounds as the fleet grows. Here are a few of the patterns platform teams see most often:
- A workaround is granted on cluster 3 for a legitimate reason but is never removed.
- Cluster 7 runs a mutating webhook that the platform team forgot about.
- A production cluster receives a security patch that changes admission behavior, but staging doesn’t receive the same patch for two months.
Multiply this across a fleet of clusters, and no one on the platform team can confidently say which rules are in force where.
2. Manual Gates Don't Scale With Growth
According to Red Hat’s 2026 State of Cloud-native Security report, 74% of organizations slowed or delayed application deployments in the past year because of security concerns. And manual review is one of the common drivers of this.
Manual gates force platform teams into one of two positions, both of which undermine enforcement.
The reviewer either becomes a rubber stamp because there isn’t time to genuinely inspect every manifest, and the gate stops providing security. Or the reviewer holds the line and becomes the bottleneck; developers route around through side channels that skip review entirely. This is the Kubernetes governance tension that manual enforcement can’t resolve on its own.
3. No Audit Trail You Can Query
Manual enforcement produces artifacts scattered across ticketing systems, Slack threads, and reviewer inboxes. So when an auditor or an incident-response team asks, “was this workload compliant when it was admitted, and if so, under which policy version?”, the answer can take days.
An automated enforcement layer produces the audit trail as a byproduct of every admission decision: timestamped, versioned, and queryable. Manual review can’t produce this because the decision itself was never structured as data.
Given that 97% of organizations experienced at least one cloud-native security incident in 2025, the absence of a queryable enforcement layer is what makes post-incident forensics expensive.
Platforms like Portainer solve this by streaming every admission decision and policy change to your SIEM of choice (Splunk, Sentinel, or a syslog target), so the audit trail exists as queryable data from day one.
{{article-cta}}
How Kubernetes Policy Enforcement Works
Every request to the Kubernetes API server passes through the same lifecycle before reaching etcd. Enforcement happens at one specific stage of that lifecycle: admission control.
The Kubernetes Request Lifecycle
Authentication and authorization run first. Authentication confirms who’s making the request, and authorization confirms they’re allowed to make it. Once both pass, the API server hands the request to the admission controllers.
Admission controllers inspect the request payload itself and decide whether the workload complies with organizational rules. Only requests that pass admission get written to etcd and become part of the cluster’s declared state.
This is the enforcement moment because it’s the last chance to reject a non-compliant workload before it comes into existence. Once a resource is stored in etcd, the scheduler and controllers will act on it.
Mutating vs Validating Admission
Kubernetes runs two categories of admission controllers in a fixed order.
Mutating admission controllers run first. They can modify the request payload before it moves on: adding a required label, injecting a sidecar, setting a default security context, or rewriting a field to meet policy. Mutation is how policy fixes small issues automatically instead of rejecting the request.
Validating admission controllers run second, after all mutations have completed. They can’t modify the request. They can only accept or reject it. This is where the concrete security rules live. Blocking privileged containers, requiring signed images from approved registries, enforcing resource quotas, denying host network access, and rejecting workloads with missing ownership labels are all validating admission decisions.
The ordering is important here. Mutation runs first so that validation evaluates the final version of the request, including any defaults or fixes the mutating layer applied.
Policy Engines: Kyverno, OPA Gatekeeper, and Pod Security Admission
Writing admission logic in Go and compiling custom controllers is possible but uncommon. Most platform teams use one of three policy engines instead, each of which plugs into the admission controller framework:
- Pod Security Admission (PSA) comes built into Kubernetes and enforces three predefined levels (privileged, baseline, restricted) at the namespace level. It’s the fastest path to enforcing the built-in security baseline without additional installation. Its limitation is that the rule set is fixed; you can’t extend it.
- Kyverno uses YAML for policy definitions, which lowers the learning curve for teams already comfortable with Kubernetes manifests. It handles mutating and validating policies, as well as generating resources based on policy triggers.
- OPA Gatekeeper uses Rego, a declarative query language purpose-built for policy. Rego has a steeper learning curve than YAML but expresses complex conditional logic more cleanly than Kyverno for policies with cross-resource dependencies or dynamic constraints.
Most fleets end up running a combination: PSA for the common security baseline, and Kyverno or OPA Gatekeeper for custom organizational rules that PSA doesn’t cover.
Where Policy-as-Code Fits In
Whichever engine a team picks, the rules themselves get written declaratively, stored in Git, and versioned like any other code. This is what makes enforcement auditable and repeatable.
Every policy change goes through review, every cluster runs the version currently checked out from the main branch, and rollbacks are a git revert.
How Teams Handle Security Policy Enforcement Across Kubernetes Clusters (Including Blocking Privileged Containers)
Teams enforce security policies across Kubernetes clusters by encoding rules like “block privileged containers” as policy-as-code, running them through a shared policy engine, and rolling them out with phased enforcement modes so nothing breaks in production. Portainer sits above this as the operator control plane, applying pod security constraints and OPA Gatekeeper policies uniformly across every cluster in the fleet from a single interface.
Here’s a six-step framework platform teams follow to get from “we should enforce policy” to “every cluster in the fleet blocks non-compliant workloads at admission time.”
Step 1: Inventory Every Cluster and Set a Security Baseline
Before writing any policy, catalog what’s already running. For each cluster, document the Kubernetes distribution and version, which admission controllers are active, which workloads run with elevated privileges, and which namespaces belong to which teams. This inventory tells you where enforcement will be trivial and where it will break things.
From the inventory, define your baseline: the minimum set of rules every cluster must enforce. Blocking privileged containers is the near-universal starting point because it’s the single highest-impact policy for reducing attack surface, and Pod Security Admission handles it natively.
Also, document exceptions before enforcement starts. Some workloads legitimately need elevated privileges (CSI drivers, network plugins, monitoring agents), and the exception list needs to be properly stored so it survives team turnover.
Step 2: Decide Which Engine (or Engines) Each Baseline Rule Runs On
We already covered what each engine (Pod Security Admission, Kyverno, and OPA Gatekeeper) does. The main question at this stage is more operational: which engine owns which rule in your fleet.
For most teams, PSA owns the built-in Kubernetes baseline, Kyverno or OPA Gatekeeper owns the custom organizational rules PSA can’t express, and the two run alongside each other rather than one replacing the other.
Portainer collapses the common cases into a UI toggle. Its built-in security constraints layer, backed by OPA Gatekeeper, exposes the most-used policies (blocking privileged containers, restricting registries, enforcing labels) as one-click enable/disable across every cluster, with no Rego to write.
For custom rules Portainer’s built-in constraints don’t cover, Kyverno or OPA Gatekeeper run alongside on the same clusters. Check out this video to see Portainer’s policy enforcement in action.
Step 3: Start With a Small, High-Impact Policy Set
Enforcement programs fail when they try to roll out dozens of policies at once. Start by picking three to five high-impact rules and enforce those before adding more. The starter set platform teams converge on:
- Block privileged containers. Prevents workloads from running with full host kernel access. Single largest reduction in attack surface for a single policy.
- Deny host network and host path. Stops workloads from reaching the host’s network stack or filesystem directly.
- Require non-root users. Blocks workloads that run as UID 0.
- Enforce image registry allowlists. Prevents workloads from pulling from untrusted or public registries.
- Require ownership labels. Every workload declares which team owns it, making debugging, chargeback, and incident response tractable.
Starting narrow gives you data. You learn which workloads violate the baseline before you have 30 more policies interacting, and you build the operational muscle to roll out policies safely before the stakes get high.
{{article-cta}}
Step 4: Manage Policy Definitions in Git
Every policy the fleet enforces lives in a Git repository, ideally the same one that holds cluster configuration. A typical repo structure keeps engine-specific manifests separated (a directory each for Kyverno, OPA Gatekeeper constraint templates, and PSA namespace labels), with a per-cluster overlay directory for exceptions and cluster-specific rules.
Changes go through a pull request. The reviewer checks the policy diff, the target clusters, and any exceptions being added or removed. Merged changes get deployed to clusters through GitOps: Argo CD, Flux, or Portainer’s built-in GitOps engine reconciles the policy state from main and applies it. This is what makes the enforcement layer fleet-wide instead of per-cluster.
Step 5: Roll Out Enforcement in Phases (Audit → Warn → Enforce)
Never turn on a new policy in enforce mode on day one. The phased rollout below prevents the classic failure where a policy blocks a legitimate workload the team didn’t know about and takes down production:
- Phase 1: Audit mode. The policy runs but only logs violations. Nothing gets blocked. Run for two to four weeks, then review the logs to identify the workloads that would have been blocked.
- Phase 2: Warn mode. Violations produce a visible warning to the developer at deploy time, but the workload still gets admitted. This makes the policy visible to the teams whose workloads violate it and gives them a window to remediate.
- Phase 3: Enforce mode. Violations block admission. Only flip to enforce once the warn phase produces zero unexpected violations.
Roll out each phase in stages: one cluster or namespace at a time. Start with non-production clusters, then move to production. This keeps the blast radius small if a policy interacts badly with a workload nobody predicted.
Step 6: Review Enforcement Data and Iterate
Review the enforcement logs across the fleet on a regular cadence, ideally every 1 to 2 weeks. Look for these three signals here:
- Policies with zero violations for months. Either the rule is redundant, or nobody’s writing workloads that would trigger it. Consider whether the policy is still earning its place.
- Policies with recurring violations from the same team. The team either needs the policy adjusted to accommodate a legitimate use case, or they need training to write compliant manifests. Treat a high violation rate as a signal to investigate.
- Workloads exploiting exceptions. Exceptions granted six months ago for one workload sometimes get copy-pasted across teams. Audit the exception list and revoke those that are no longer justified.
Enforcement is an ongoing operational discipline. The policy set evolves with the fleet, the applications, and the threat model, and the teams that get this right treat their policy repo like production code, with regular pruning, tuning, and additions.
Use Portainer to Enforce Policy Across Your Kubernetes Clusters
Kubernetes policy enforcement holds up when the same rules apply to every cluster in the fleet, get versioned like code, and roll out through phases that don’t break production.
Portainer is the operator control plane for Kubernetes and Docker. Its built-in security constraints layer, backed by OPA Gatekeeper, exposes the most-used enforcement policies as one-click toggles across every cluster in the fleet: block privileged containers, restrict registries, enforce labels, deny host network access.
For rules the built-in constraints don’t cover, OPA Gatekeeper and Kyverno run alongside on the same clusters, applied and versioned through Portainer’s GitOps engine. RBAC scopes policies to teams and namespaces, and every admission decision gets logged and can be streamed to any SIEM for audit.
Want to see how Portainer handles policy enforcement across your fleet? Book a demo to see it running against your setup.
FAQs
1. How do people handle security policy enforcement across Kubernetes clusters, like blocking privileged containers?
Most teams handle it by encoding rules as policy-as-code, running them through admission controllers via Pod Security Admission, Kyverno, or OPA Gatekeeper, and rolling them out in phased modes (audit, warn, enforce). Portainer collapses the common cases like blocking privileged containers into one-click toggles that apply across every cluster in the fleet.
2. Kyverno or OPA Gatekeeper, which should I use?
Use Kyverno if your team is comfortable with YAML and most of your policies fit that shape (labels, registries, defaults). Use OPA Gatekeeper if you need complex conditional logic or cross-resource evaluation where Rego’s expressiveness justifies its learning curve. Many fleets run both.
3. Is Pod Security Admission enough on its own?
Sometimes. PSA covers the highest-frequency baseline rules (privileged containers, host access, root users) natively without extra installation, which is enough for smaller teams or non-regulated workloads. For custom organizational rules, image registry restrictions, or compliance-specific policies, add Kyverno or OPA Gatekeeper alongside.
4. What is policy-as-code?
Policy-as-code is the practice of writing enforcement rules as declarative files stored in Git. Rules get reviewed in pull requests, deployed through CI/CD pipelines, and applied consistently to every cluster from a single source of truth.
5. Will policy enforcement slow developers down?
No, if it’s automated and phased in properly. Compliant manifests get admitted at API-server latency with no human review. Non-compliant ones fail immediately with a specific error the developer can fix on their own. What slows delivery is manual review, not enforcement itself.
