More Info:
Do not generally permit containers to be run with the securityContext.privileged flag set to true.Risk Level
CriticalAddress
SecurityCompliance Standards
- APRA CPS 234 (Australia)
- BSI C5 (Germany)
- Brazil LGPD
- CCPA / CPRA (California)
- CIS Critical Security Controls v8
- CIS GKE
- CMMC 2.0
- CSA Cloud Controls Matrix v4
- DPDPA
- Digital Operational Resilience Act (EU)
- Essential 8
- ISO/IEC 27017
- ISO/IEC 27018
- ISO/IEC 27701
- KSA PDPL
- MAS Technology Risk Management (Singapore)
- MITRE ATT&CK (Cloud)
- NIS2 Directive
- NIST SP 800-171
- NYDFS 23 NYCRR 500
- SWIFT Customer Security Controls Framework
- Sarbanes-Oxley IT General Controls
- UK NCSC Cyber Assessment Framework
Triage and Remediation
- Remediation
Remediation
Manual Steps
Manual Steps
-
List all pods using privileged containers (evidence gathering)
- Run on: any machine with kubectl access
Save the output as your initial inventory of privileged pods. -
Identify how privileged pods are being admitted (exemptions, policies, namespaces)
- Run on: any machine with kubectl access
a) Check Pod Security admission labels on each namespace:
b) If using Pod Security Policies (legacy) in this cluster, list them and inspect theprivilegedfield and related rules:Review which namespaces/service accounts are allowed to use PSPs that permitprivileged: true(via RBACusebindings). - Run on: any machine with kubectl access
-
Classify privileged usage as required or unnecessary
For each pod from step 1, review its purpose and image, and determine ifsecurityContext.privileged: trueis strictly required (e.g., node-level monitoring, CNI, storage, low‑level debugging) or if finer-grained capabilities / other mechanisms would suffice.- To inspect the full pod spec for a specific pod:
Decide pod-by-pod whether to (a) keep privileged, (b) remove privileged, or (c) replace with narrower capabilities (e.g.,capabilities.add). -
Remove or reduce privileged settings where not strictly needed
- Run on: any machine with kubectl access (editing manifests in your Git/IaC system is strongly recommended; use
kubectl editonly for temporary/urgent changes).
For each workload determined unnecessary to be privileged:
a) Locate and edit its Deployment/StatefulSet/DaemonSet/Job manifest.
b) In each relevant container spec, either remove theprivilegedsetting or set it to false:
c) Apply the updated manifest:Note: Changing controller specs will recreate pods; plan for any resulting restarts or brief disruption. - Run on: any machine with kubectl access (editing manifests in your Git/IaC system is strongly recommended; use
-
Tighten admission controls for future pods
- If using Pod Security (recommended on GKE):
- Set stricter labels (e.g.,
pod-security.kubernetes.io/enforce=restricted) on namespaces that should not allow privileged pods:
- Set stricter labels (e.g.,
- If still using Pod Security Policies and they’re enabled in this cluster, ensure the PSPs bound to general workloads omit
.spec.privilegedor set it tofalse, and restrictuseof any PSP that allows privileged containers only to specific service accounts/namespaces that require it.
- If using Pod Security (recommended on GKE):
-
Re-verify and document accepted exceptions
- Run on: any machine with kubectl access
Re-run the evidence command from step 1 to confirm only intentionally approved privileged workloads remain:
For any remaining privileged pods, record: namespace, controller (Deployment/DaemonSet/etc.), business owner, and justification, and ensure their namespaces/policies are explicitly configured as controlled exceptions. - Run on: any machine with kubectl access
Using kubectl
Using kubectl
securityContext.privileged=true. Each match requires human review to decide if it is strictly necessary..spec.containers[].securityContext and .spec.initContainers[].securityContext:privileged: trueindicates a privileged container. Decide whether the privilege is justified; if not, the workload manifest must be changed and redeployed.
securityContext.privileged: true. These controllers will continue to create privileged pods until their manifests are changed.- Namespaces with
enforce=privileged(or with no enforce label, depending on your cluster defaults) may admit privileged pods. - Namespaces intended to be restricted should typically use
enforce=baselineorrestricted. Any more‑permissive configuration should be reviewed.
- A PSP with
.spec.privileged: trueor missing.spec.privilegedbut effectively permitting privileged pods (depending on other fields and RBAC bindings) is a potential concern. - Validate which service accounts / users are bound to such PSPs with RBAC:
system:serviceaccounts:<namespace>) should be carefully reviewed.Automation
Automation
- Lines in sections 1 or 2: pods/containers with
PRIVILEGED=true/PRIVILEGED_REQUESTED=true. - Namespaces in section 3 with Pod Security labels set to
privileged(or a custom policy allowing privileged). - PSPs in section 4 with
PRIVILEGED_ALLOWED=true.

