Skip to main content

More Info:

Every namespace with user workloads should be governed by Pod Security Admission or an external policy engine to enforce pod security standards.

Risk Level

Medium

Address

Security

Compliance Standards

  • CIS Kubernetes

Triage and Remediation

Remediation

Manual Steps

  1. Identify namespaces with user workloads
    • Run on: any machine with kubectl access
    • Command:
    • Decide which namespaces contain user applications (exclude clearly system ones like kube-system, kube-public, kube-node-lease, and any cloud-provider/system namespaces your platform uses).
  2. Check Pod Security Admission labels on those namespaces
    • Run on: any machine with kubectl access
    • Command (replace USER_NAMESPACE with each identified namespace):
    • Review whether labels like pod-security.kubernetes.io/enforce, pod-security.kubernetes.io/warn, or pod-security.kubernetes.io/audit are present and set to an appropriate level (baseline or restricted for enforce).
  3. Check for external policy engines (e.g., Gatekeeper, Kyverno) in the cluster
    • Run on: any machine with kubectl access
    • Commands:
    • If present, note which engine(s) are installed (e.g., Gatekeeper, Kyverno).
  4. Verify that policies actually cover the user namespaces
    • Run on: any machine with kubectl access
    • For Gatekeeper-like engines:
    • For Kyverno-like engines:
    • Inspect sample policies to confirm they apply cluster-wide or explicitly to each user namespace via spec.match / namespaceSelector (use kubectl get <kind> <name> -o yaml as needed).
  5. Decide and apply remediation where gaps exist
    • If a user namespace has neither Pod Security Admission labels nor coverage by an external policy engine:
      • Option A (Pod Security Admission):
      • Option B (External policy engine): create or update policies to include that namespace in their match rules, then apply them with kubectl apply -f POLICY_FILE.yaml.
  6. Verify that every user namespace is now governed by at least one mechanism
    • Run on: any machine with kubectl access
    • Commands:
    • Confirm that either PSA labels enforce a profile or the external engine denies or modifies non-compliant pods in each user namespace.
How to review the output
  • From command (1):
    • Problem indication: Any namespace that:
      • Contains user workloads (e.g., dev, prod, staging, app-specific namespaces), and
      • Shows "<none>" or empty values in all three columns POD-SECURITY-ENFORCE, POD-SECURITY-AUDIT, and POD-SECURITY-WARN.
    • These namespaces are not covered by Pod Security Admission and require either PSA labels or an external policy engine.
  • From command (2):
    • Inspect .metadata.labels for:
      • pod-security.kubernetes.io/enforce
      • pod-security.kubernetes.io/enforce-version
      • pod-security.kubernetes.io/audit
      • pod-security.kubernetes.io/warn
    • Problem indication: User-workload namespaces without any of these labels, or labels set to a profile that is weaker than your organization’s required standard (e.g., privileged where your standard is baseline or restricted).
  • From command (3):
    • Problem indication: No Gatekeeper or Kyverno pods running and no constraints/policies defined, combined with user-workload namespaces that also lack PSA labels.
    • In that case, those namespaces have no active policy control mechanism.
  • From command (4):
    • The printed list is all namespaces with no PSA labels.
    • Problem indication: Any namespace in this list that you identify as running user workloads and that is also not governed by an external policy engine (from step 3) fails the control and requires a design decision and remediation.