Table of contents
Most Kubernetes security teams already have an admission controller: OPA/Gatekeeper, Kyverno, a custom webhook. Real work, producing real enforcement. But it’s completely disconnected from everything else they know about their environment.
Whether Orca has flagged a cluster as exposed or an image has a critical CVE—none of this context reaches the policy engine. The admission controller enforces what the policy says, not what the risk intelligence knows.
Enter Orca’s Admission Controller.
Why Detection Alone Isn’t Enough
Kubernetes admission control isn’t a new problem. Security architects have understood for years that the right place to catch a bad configuration is before the resource is created, not after it’s running in production.
The challenge has been turning that understanding into action at scale, without adding friction to developer workflows or requiring a dedicated engineering effort to maintain a separate policy stack.
Platform and DevSecOps engineers who have tried to solve this with open-source tooling like OPA/Gatekeeper, Kyverno, and custom webhook configurations, know the pattern well. You write policies in Rego or YAML. You deploy and maintain a separate admission controller per cluster. You manage policy libraries in a Git repository. You stitch together audit outputs from the policy engine with alerts from your security platform. And when a policy blocks a legitimate workload, you context-switch between tools to figure out why.
It works. But it works the way most DIY security infrastructure works: with a maintenance burden that competes with the work it was built to enable, and with the policy layer living entirely separately from the risk intelligence that should be informing it.
For cloud security engineers, this creates a persistent gap between knowledge and action. Orca surfaces a finding, like a privileged container, untrusted registry, or missing required label. The remediation path runs through a separate tool, a separate team, and a separate policy definition that doesn’t share context with the alert that triggered it.
For CISOs, the consequence is an attack surface that stays open longer than it should. Detection without enforcement means every misconfiguration that makes it to production has to be found, triaged, and remediated after the fact. It’s a reactive cycle that compounds as cluster count grows.
The structural gap isn’t that teams don’t have an admission controller. It’s that the admission controller they have can’t act on what Orca knows.
From Observation to Enforcement In One Platform
Orca’s Admission Controller is an Orca-managed component that you deploy into your Kubernetes clusters. When a resource creation or update request hits the Kubernetes API server, the Admission Controller evaluates it against the controls and policies you’ve defined in Orca, and either allows it, warns, or blocks it, depending on how your policy is configured.
The key distinction from standalone tooling is that the Admission Controller is managed entirely from within Orca. Controls, policies, cluster assignments, enforcement modes, and event visibility all live in the same interface where you already manage cloud risk, vulnerabilities, and misconfigurations. The context you’ve built in Orca about your environment, your clusters, and your risk posture, now informs what gets blocked at the gate.
There’s no separate policy management plane. No additional dashboard. No context-switching. For platform engineers already running Kubernetes security through Orca, this means enforcement becomes another capability in the platform they already operate, not another system to maintain alongside it.
How It Fits Into Orca’s Kubernetes Security Architecture
The Admission Controller is the third leg of Orca’s Kubernetes security stack, and each layer has a distinct job:
- Kubernetes Connector: Allows Orca to inventory and scan private clusters.
- Orca Sensor: Detects runtime threats so you know what’s happening in production right now.
- Admission Controller: Enforces security policy at admission time so you stop problems before they get in.
This is the full arc from observation to action. Visibility tells you the state of your environment. Detection tells you what’s changing at runtime. Enforcement acts on what you know before the damage is done. All three capabilities now live in the same platform, informed by the same data model, so the gap between knowing something is risky and doing something about it closes.
Enforce or Audit. Your Choice.
Every policy in Orca’s Admission Controller runs in one of two modes:
Block mode stops the non-compliant request before it reaches the cluster. The violation is recorded, the workload doesn’t deploy.
Warn mode lets the request through but records a violation event. This is the right mode for teams moving from observation to enforcement gradually. You can see exactly what a policy would block before making it hard enforcement, without impacting developer velocity in the meantime.
This distinction matters in practice. Security teams that have tried to go directly to hard enforcement on production clusters know the friction that creates with developers. Starting in warn mode lets you observe the full blast radius of a policy before you act on it, then graduate to block when you’re confident. Audit-first is how good policy rollouts happen, and it’s how security engineering earns trust from platform teams.
12 Built-In Control Templates, Covering the Scenarios That Matter
Rather than requiring teams to write policy logic from scratch, the Admission Controller ships with 12 built-in control templates covering the most common Kubernetes security and governance use cases, organized across five categories:
Access Control and Isolation: Block interactive shell access (kubectl exec -it), which reduces attack surface and prevents lateral movement after compromise.
Application Health and Reliability: Require liveness and readiness probes so Kubernetes can detect and route around unhealthy or compromised containers before they affect traffic.
Image Security and Supply Chain: Four templates covering the full spectrum of image risk: enforce approved registries (allowlist), block known-bad registries (blocklist), prevent mutable tags like latest, and require cryptographic SHA256 image digests to protect against tag tampering and supply-chain attacks.
Metadata and Governance: Require mandatory annotations (owner, cost-center, security-tier) and labels (app, environment) so that every workload is attributable, traceable, and segmented correctly. Missing labels don’t just create governance gaps — they break security automation that depends on them.
Pod Security: Four templates targeting the highest-risk container configurations: block privilege escalation, block host namespace access (hostPID/hostIPC), block privileged containers (one of the most dangerous default-open configurations in Kubernetes), and enforce read-only root filesystems to prevent persistence and webshell creation.
Controls are built from these templates, then grouped into policies. A single policy can contain multiple controls, evaluated together, and a single policy can be assigned to specific clusters or to all clusters in a cloud account. For security engineers, this is how organizational standards stop being findings and start being policy: define the control once, attach it everywhere it applies, enforce it at the gate.
Cluster Management from a Single Pane of Glass
Deploying the Admission Controller is a Helm command away, generated and provided by Orca. Select the cloud account, select the cluster, copy the command, run it in your terminal. Verification happens directly in the Orca UI and the cluster’s Features column confirms installation status.
Once deployed, the cluster appears in Settings > Connections > Cluster Management, where you can see which clusters have the Admission Controller installed, review the enforcement posture across your fleet, and manage policy assignments, all without leaving the platform. Policy drift across clusters doesn’t require cross-tool reconciliation. Enforcement status is visible where risk is already being tracked.
Close the Loop with Full Event Visibility
Every request the Admission Controller evaluates generates an event reported back to Orca. The Event Stream shows what was evaluated, which policy applied, whether it was allowed or blocked, the Kubernetes resource involved, and the actor that initiated the request.
Observation doesn’t stop at the gate. Every enforcement decision feeds back into Orca, so you can review what’s being blocked, investigate deployment issues, and audit policy compliance across clusters, all in one place. For security leaders, this is the audit trail that makes enforcement posture visible and defensible: not buried in cluster logs, but surfaced in the same platform where risk is being measured.
About the Orca Cloud Security Platform
The Orca Platform delivers a unified cloud security experience that helps organizations identify, prioritize, and remediate risk across their cloud environments, applications, and AI.
Ready to close the gap between observation and action? Request a personalized 1:1 demo.
Chat with an Orca Expert