In government Kubernetes deployments, the admission control layer is where security policy is enforced before workloads reach the cluster. A deployment that violates security policy — running as root, using a non-approved image registry, missing required labels — should be rejected at admission, not discovered after the fact during a STIG scan or security audit.
Here's how Rutagon implements Kubernetes admission control on government cloud programs.
The Admission Controller Architecture
Kubernetes admission controllers intercept API server requests after authentication and authorization, before persisting objects to etcd. Two types:
Validating admission webhooks: Inspect the incoming request and allow or deny it. The webhook cannot modify the resource.
Mutating admission webhooks: Can modify resources before they're persisted — adding sidecar containers, injecting labels, setting default values.
For security policy enforcement, validating webhooks are primary. Mutating webhooks handle automatic security context injection and label enforcement.
Policy enforcement frameworks that implement admission webhooks for Kubernetes:
Kyverno: Kubernetes-native policy engine — policies written in YAML (no Rego required), tightly integrated with Kubernetes resource model. Easier learning curve; appropriate for most government programs.
OPA Gatekeeper: Uses OPA Rego for policy logic. More expressive for complex policies; higher learning curve. Better choice for programs already using OPA for infrastructure policy.
Pod Security Admission (built-in): Kubernetes 1.25+ replaced PodSecurityPolicy (deprecated) with Pod Security Admission — a built-in controller that enforces three profiles: privileged, baseline, and restricted. For government clusters, restricted profile is the baseline.
Rutagon uses Kyverno + Pod Security Admission on most government programs — Kyverno for custom policy logic, PSA for baseline pod security enforcement.
Critical Policies for DISA STIG Compliance
Block privileged containers (CAT I finding if not enforced):
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
name: disallow-privileged-containers
spec:
validationFailureAction: Enforce
rules:
- name: check-privileged
match:
any:
- resources:
kinds: [Pod]
validate:
message: "Privileged containers are not allowed."
pattern:
spec:
containers:
- =(securityContext):
=(privileged): "false"
Enforce approved image registries:
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
name: require-approved-registry
spec:
validationFailureAction: Enforce
rules:
- name: check-registry
match:
any:
- resources:
kinds: [Pod]
validate:
message: "Images must be from an approved registry."
pattern:
spec:
containers:
- image: "registry1.dso.mil/* | ${GOVCLOUD_ECR_REGISTRY}/*"
Require security context constraints:
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
name: require-run-as-non-root
spec:
validationFailureAction: Enforce
rules:
- name: check-run-as-non-root
match:
any:
- resources:
kinds: [Pod]
validate:
message: "Containers must run as non-root user."
pattern:
spec:
securityContext:
runAsNonRoot: true
containers:
- securityContext:
runAsNonRoot: true
Automated Policy Generation for ATO Evidence
For ATO purposes, the ISSO needs to know what security policies are enforced and how violations are handled. Kyverno's policy reports provide this:
# PolicyReport — generated automatically by Kyverno
apiVersion: wgpolicyk8s.io/v1alpha2
kind: PolicyReport
metadata:
name: polr-ns-production
namespace: production
results:
- policy: require-run-as-non-root
rule: check-run-as-non-root
result: pass
timestamp: "2026-05-08T09:32:14Z"
- policy: disallow-privileged-containers
rule: check-privileged
result: pass
These reports are automatically collected and included in the ATO evidence package — providing the ISSO with continuous evidence that security policies are being enforced on every deployed workload.
Exceptions Management
Production systems sometimes legitimately need exceptions to standard policies — a monitoring agent that needs elevated privileges, a legacy component that hasn't been updated to run as non-root yet. Handling exceptions without undermining the policy framework:
Kyverno exceptions:
apiVersion: kyverno.io/v2alpha1
kind: PolicyException
metadata:
name: monitoring-privileged-exception
namespace: monitoring
spec:
exceptions:
- policyName: disallow-privileged-containers
ruleNames: ["check-privileged"]
match:
any:
- resources:
kinds: [Pod]
namespaces: [monitoring]
names: [node-exporter-*]
Each exception is documented with: the policy being excepted, the specific workload, the justification, and the planned remediation date. Exceptions are tracked in the POA&M.
View Rutagon's Kubernetes engineering capabilities → rutagon.com/government
Frequently Asked Questions
What happens when a policy violation is detected on a government cluster?
Enforce mode policies block the deployment immediately — the API server returns an error to the deploying process. The violation is logged in Kubernetes audit logs. Kyverno generates a PolicyReport entry recording the violation. Monitoring alerts trigger if the policy violation rate exceeds expected levels (indicating a misconfigured deployment process). ATO evidence includes the audit log and policy report showing how violations are handled.
How does admission control integrate with the CI/CD pipeline?
Admission control is a last line of defense at runtime — but policy violations should be caught earlier. Kyverno policies can be validated in CI/CD using kyverno apply against manifests before deployment. This shifts violation detection left: a manifest that would fail admission control fails the pipeline before it ever reaches the cluster. Runtime enforcement catches anything that slips through the CI/CD gate.
What's the difference between Pod Security Admission and Kyverno for government use?
Pod Security Admission (PSA) enforces fixed profiles (privileged/baseline/restricted) at the namespace level. It's simple and built-in but inflexible — the profiles are fixed by Kubernetes and can't be customized. Kyverno allows custom policies with detailed control logic. For government programs, both should be used: PSA for baseline pod security enforcement, Kyverno for program-specific policies (approved registries, required labels, resource limits). The two are complementary.
Can admission webhooks be bypassed?
Admission webhooks can fail open or fail closed depending on the failurePolicy setting. For security-critical policies, failurePolicy: Fail ensures that if the webhook is unavailable, requests are denied rather than allowed. Webhooks should be deployed with high availability (multiple replicas) and monitored for availability. Rutagon configures security-critical policies with failurePolicy: Fail and webhook pod disruption budgets to prevent unintended availability gaps.
How do you handle policy violations from third-party operators and add-ons?
Helm charts and operators from third parties frequently include pods that don't conform to restricted security policies (running as root, using broad privileges). Kyverno exceptions are the standard handling: document the exception, scope it precisely to the affected namespace and workload names, and track remediation if the vendor releases a security-updated version. For Iron Bank programs, only Iron Bank-approved images are acceptable — forcing use of Iron Bank images from third-party components eliminates most security context violations.