Notifications
Clear all
Topic starter
09/07/2026 3:19 pm
TL;DR: Kubernetes admission controllers often enforce policy without the broader risk context security teams already have, leaving exposed clusters, vulnerable images, and governance gaps to be handled separately, according to Orca Security. The operational issue is not whether enforcement exists, but whether it is informed by the same intelligence that drives detection and remediation.
NHIMG editorial — based on content published by Orca Security: Kubernetes admission control and the gap between detection and enforcement
Questions worth separating out
Q: How should security teams use Kubernetes admission control without slowing delivery?
A: Start with warn mode for policies that are likely to hit existing workloads, then move the highest-risk controls to block mode once you understand the blast radius.
Q: Why do Kubernetes policies fail when they are disconnected from security findings?
A: They fail because the policy engine only enforces the rules it knows, while the security team may already know that a cluster is exposed or an image is risky.
Q: What do teams get wrong about Kubernetes admission controllers?
A: They often treat admission as a standalone gate instead of the final decision point in a broader risk workflow.
Practitioner guidance
- Unify risk signals before enforcement Connect admission decisions to the same cluster exposure, vulnerability, and misconfiguration findings that your security team already trusts.
- Roll out policy in warn mode first Use warn mode to measure how often legitimate workloads would be blocked, then move specific controls to block mode once the blast radius is understood.
- Prioritise admission controls that prevent high-impact misuse Start with controls for privileged containers, host namespace access, mutable image tags, and unapproved registries because these are common paths to persistence and supply-chain compromise.
What's in the full article
Orca Security's full article covers the operational detail this post intentionally leaves for the source:
- Deployment flow for the Orca-managed Admission Controller, including the cluster installation steps and verification points.
- The full set of 12 built-in control templates, including exact enforcement scenarios for image provenance, pod hardening, and metadata requirements.
- Event Stream details showing what is evaluated, what was blocked or allowed, and how the audit trail is surfaced in the platform.
- Cluster management views that show enforcement posture across multiple clusters without leaving the console.
👉 Read Orca Security's analysis of Kubernetes admission control with risk context →
Kubernetes admission control - are your controls using risk context?
Explore further
09/07/2026 3:37 pm
Disconnected enforcement is a governance failure, not a tooling gap. The article shows that a policy engine enforcing in isolation can satisfy the letter of control without using the environmental context that makes control effective. That is the structural problem in many Kubernetes programmes: detection, policy, and remediation are treated as separate workflows even when the same risk conditions drive all three. Practitioners should view this as an integration failure across the decision path, not a missing feature list.
A few things that frame the scale:
- The average organisation believes more than 1 in 5 of their non-human identities are insufficiently secured, according to The 2024 ESG Report: Managing Non-Human Identities.
- Enterprises that have experienced a compromised NHI averaged 2.7 separate incidents in the past 12 months, a pattern that shows how identity exposure tends to compound once governance fails.
A question worth separating out:
Q: Who should own Kubernetes admission policy enforcement?
A: Ownership usually sits with platform and cloud security teams together, because admission policy affects workload delivery, cluster posture, and governance evidence. The important point is that the same team must be able to see the risk signals, define the controls, and review the resulting events. Otherwise the control becomes hard to tune and harder to defend.
👉 Read our full editorial: Kubernetes admission control needs risk context, not just policy
