Kubernetes Admission Policy Action Management

Kubernetes Admission Policy Action Management is the practice of choosing and evolving the enforcement action — deny, warn, or audit — applied when a policy check fails, across the different Kubernetes mechanisms that support this concept, and managing the transition between actions deliberately as confidence in a policy's correctness grows. The available actions and how they are configured differ across mechanisms, making this a cross-cutting concern that spans Pod Security Standards, ValidatingAdmissionPolicy, and custom policy engines.

Action Semantics Across Mechanisms

Pod Security Standards

Pod Security admission expresses actions through separate namespace labels — enforce, audit, and warn — each independently settable to its own standard, allowing a namespace to enforce baseline while auditing against restricted simultaneously.

metadata:
  labels:
    pod-security.kubernetes.io/enforce: baseline
    pod-security.kubernetes.io/audit: restricted

ValidatingAdmissionPolicy

ValidatingAdmissionPolicyBinding expresses actions through the validationActions field, which accepts Deny, Warn, and Audit, and can list multiple actions simultaneously on a single binding — for instance, ["Warn", "Audit"] together, both applying without blocking the request.

spec:
  validationActions: ["Warn", "Audit"]

Webhook-Based Policy Engines

Traditional validating webhooks natively support only allow or deny at the API server level; policy engines like Kyverno and OPA Gatekeeper implement their own equivalent of warn and audit modes above this binary primitive, typically through a validationFailureAction field or similar construct specific to the engine, meaning the mechanics differ from the native Kubernetes constructs even though the conceptual model is the same.

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: require-labels
spec:
  validationFailureAction: Audit

Choosing an Action Deliberately

Matching Action to Policy Maturity

A newly authored policy should generally start in Audit or Warn mode regardless of mechanism, since its real-world impact against existing workloads is unknown until observed; only after reviewing the resulting audit entries or warnings and confirming no unintended rejections would occur should the action be escalated to Deny or enforce.

Matching Action to Policy Severity

A policy addressing a genuine security requirement (blocking privileged containers, requiring approved image registries) generally warrants eventual Deny/enforce, while a policy addressing a softer best practice (recommended labeling conventions, naming standards) may remain permanently at Warn if the organization prefers guidance over hard blocking for that category of concern.

Managing the Transition Between Actions

Tracking Audit and Warning Volume Before Escalating

Before moving a policy from an observational action to Deny/enforce, reviewing the volume and distribution of violations recorded during the observation period — which teams, which namespaces, how frequently — informs whether escalation would cause disruption and whether remediation work needs to happen first.

kubectl get events --field-selector reason=ValidatingAdmissionPolicyViolation

Communicating Action Changes to Affected Teams

Because moving a policy to Deny changes previously-successful deployments into rejected ones, notifying the teams whose workloads were observed violating the policy during the audit period, and giving them a remediation window, avoids an escalation surprising teams with sudden deployment failures.

Auditing the Current Action Configuration

Enumerating Actions Across Mechanisms

Because action configuration is scattered across namespace labels, ValidatingAdmissionPolicyBinding objects, and policy-engine-specific fields, building a consolidated view of which policies are currently enforced (Deny/enforce) versus merely observed (Warn/Audit) requires querying each mechanism separately and combining the results, since no single command surfaces the complete picture across all of them.

kubectl get namespaces -o jsonpath='{range .items[*]}{.metadata.name}{"\t"}{.metadata.labels.pod-security\.kubernetes\.io/enforce}{"\n"}{end}'
kubectl get validatingadmissionpolicybindings -o jsonpath='{range .items[*]}{.metadata.name}{"\t"}{.spec.validationActions}{"\n"}{end}'

Identifying Policies Stuck in Observation Mode

A policy that has remained in Audit or Warn for an extended period without ever being escalated to Deny may indicate either an unresolved compliance gap that was never remediated, or a policy that was introduced but never revisited — periodic review of action configuration should specifically flag long-standing observational policies for a decision on whether to escalate, adjust, or retire them.