Skip to main content

More Info:

Every Kubernetes cluster should have at least one policy control mechanism in place to enforce the other requirements in this section. This could be the in-built Pod Security Admission controller, or a third party policy control system.

Risk Level

Medium

Address

Security

Compliance Standards

  • CIS Kubernetes

Triage and Remediation

Remediation

Manual Steps

  1. Inventory namespaces and identify user-workload namespaces
    • Run on: any machine with kubectl access
    • Command:
    • Manually identify which namespaces contain user workloads (non-system, non-infra), e.g., by name, labels, or by listing workloads:
    • Make a list of user-workload namespaces that must be covered by a policy control mechanism.
  2. Check for Pod Security Admission (PSA) configuration on each user namespace
    • Run on: any machine with kubectl access
    • For each identified user namespace <ns>, inspect PSA labels:
    • Verify at least the pod-security.kubernetes.io/enforce label is set to a valid level (baseline or restricted, and optionally version labels):
      • pod-security.kubernetes.io/enforce
      • pod-security.kubernetes.io/enforce-version (optional)
    • If PSA labels are missing or set to privileged, plan to either apply appropriate PSA labels or use an external policy system in the next steps.
  3. Review for external policy control systems (e.g., Gatekeeper, Kyverno)
    • Run on: any machine with kubectl access
    • Check if common policy engines are installed:
    • If you find such a system, list cluster-level policies to confirm it is actively enforcing:
    • Manually review these policies to confirm they apply to the user-workload namespaces and enforce security requirements (e.g., disallow privileged, host networking, etc.).
  4. Decide on remediation approach per namespace (PSA vs. external policy)
    • For each user-workload namespace not adequately covered by PSA or an external policy:
      • Option A (PSA): choose an appropriate level (baseline for minimal protections, restricted for stricter isolation) based on application needs.
      • Option B (external policy): design or select policies that cover the same security concerns for that namespace.
    • Document the choice per namespace and any exceptions where stricter policies would break required workloads, including risk justification.
  5. Apply or adjust policy controls for uncovered namespaces
    • Run on: any machine with kubectl access
    • To enable or strengthen PSA on a namespace <ns>:
      (Change baseline to restricted if appropriate.)
    • For external policy engines, create or update policies so that the namespaceSelector, match rules, or similar constructs explicitly include the uncovered namespaces and enforce your required controls (use the engine’s standard manifests and tools).
    • If you intentionally exclude a namespace from these mechanisms (for example, an internal admin-only namespace), record this as a formal exception with the rationale and compensating controls.
  6. Verify effective coverage across all user-workload namespaces
    • Run on: any machine with kubectl access
    • Re-check PSA labels and external policy objects:
    • Optionally, attempt to create a clearly non-compliant test pod in a covered namespace and confirm it is rejected (adapted to your chosen mechanism), then delete any test resources.
    • Confirm that every namespace with user workloads is now governed by at least one active policy control mechanism (PSA and/or external), and that this is captured in your cluster’s security documentation.
Review for each user workload namespace (anything other than kube-system, kube-public, kube-node-lease, and provider/system namespaces like gatekeeper-system, kyverno, etc.):
  • If none of these labels are present, PSA is effectively off:
    • pod-security.kubernetes.io/enforce
    • pod-security.kubernetes.io/audit
    • pod-security.kubernetes.io/warn
  • If pod-security.kubernetes.io/enforce exists but is set to a very permissive level (e.g. privileged) for user workloads, this is likely a policy gap.

Problem indicators:
  • User workload namespaces appear with all three columns as <none>.
  • Critical namespaces where you expect restrictions (e.g. production, staging) show enforce=privileged without a compensating external policy mechanism.

Problem indicators:
  • gatekeeper-system namespace missing, or no Gatekeeper pods in Running/Ready state.
  • No ConstraintTemplate or Constraint resources defined, meaning Gatekeeper is present but not enforcing anything.

Problem indicators:
  • kyverno namespace missing, or Kyverno pods not Running/Ready.
  • No ClusterPolicy/Policy resources, or all are disabled (spec.validationFailureAction=Audit everywhere when you expect enforcement).

Problem indicators:
  • Policies only in audit/warn mode where enforcement is required.
  • Policies scoped only to a subset of namespaces, leaving others with user workloads completely unprotected.

Human review needed:
  • For each namespace that actually runs user pods, confirm at least one of:
    • Pod Security Admission labels are set to an appropriate level (baseline or restricted) with enforce configured, or
    • An external policy system (Gatekeeper/Kyverno/other) is installed, healthy, and has policies that clearly apply to that namespace and relevant pod specs.
If any user workload namespace has neither PSA enforcement nor clearly-applied external policies, that namespace fails this control.

Additional Reading: