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
MediumAddress
SecurityCompliance Standards
- CIS Kubernetes
Triage and Remediation
- Remediation
Remediation
Manual Steps
Manual Steps
-
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.
-
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/enforcelabel is set to a valid level (baselineorrestricted, and optionally version labels):pod-security.kubernetes.io/enforcepod-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.
-
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.).
-
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 (
baselinefor minimal protections,restrictedfor stricter isolation) based on application needs. - Option B (external policy): design or select policies that cover the same security concerns for that namespace.
- Option A (PSA): choose an appropriate level (
- Document the choice per namespace and any exceptions where stricter policies would break required workloads, including risk justification.
- For each user-workload namespace not adequately covered by PSA or an external policy:
-
Apply or adjust policy controls for uncovered namespaces
- Run on: any machine with kubectl access
- To enable or strengthen PSA on a namespace
<ns>:(Changebaselinetorestrictedif appropriate.) - For external policy engines, create or update policies so that the
namespaceSelector,matchrules, 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.
-
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.
Using kubectl
Using kubectl
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/enforcepod-security.kubernetes.io/auditpod-security.kubernetes.io/warn
- If
pod-security.kubernetes.io/enforceexists but is set to a very permissive level (e.g.privileged) for user workloads, this is likely a policy gap.
- User workload namespaces appear with all three columns as
<none>. - Critical namespaces where you expect restrictions (e.g.
production,staging) showenforce=privilegedwithout a compensating external policy mechanism.
gatekeeper-systemnamespace missing, or no Gatekeeper pods inRunning/Readystate.- No
ConstraintTemplateorConstraintresources defined, meaning Gatekeeper is present but not enforcing anything.
kyvernonamespace missing, or Kyverno pods notRunning/Ready.- No
ClusterPolicy/Policyresources, or all are disabled (spec.validationFailureAction=Auditeverywhere when you expect enforcement).
- 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.
- For each namespace that actually runs user pods, confirm at least one of:
- Pod Security Admission labels are set to an appropriate level (
baselineorrestricted) withenforceconfigured, or - An external policy system (Gatekeeper/Kyverno/other) is installed, healthy, and has policies that clearly apply to that namespace and relevant pod specs.
- Pod Security Admission labels are set to an appropriate level (
Automation
Automation

