# Minimize the admission of privileged containers

- Source: https://support.icompaas.com/support/solutions/articles/62000234721-minimize-the-admission-of-privileged-containers
- Section: [Solutions](https://support.icompaas.com/support/solutions) › [CIS Kubernetes Benchmark v1.9.0](https://support.icompaas.com/support/solutions/62000112690) › [CIS Kubernetes Benchmark](https://support.icompaas.com/support/solutions/folders/62000169256)
- Last updated: 2026-05-29
- Publisher: iCompaas, Inc. (https://www.icompaas.com)

###  Profile Applicability:

-   **Level 1**  
    

Description: Privileged containers have elevated access to the host system and can perform operations that normal containers cannot. This check ensures that containers with the privileged flag enabled are minimized and restricted to only those workloads that absolutely require elevated privileges, thus reducing the attack surface and improving the overall security of the Kubernetes environment.

Rationale: Privileged containers run with full capabilities on the host system, which can be a major security risk. Allowing containers to be privileged opens up the potential for privilege escalation attacks, making the container a stepping stone for attackers to compromise the host system. By minimizing privileged containers, we reduce the risk of unauthorized access to the host and the underlying resources.

Impact:

Pros:  

-   Reduces the risk of privilege escalation and attacks on the host system.  
    
-   Ensures that containers only have the necessary permissions to function, reducing their potential impact in case of compromise.  
    

Cons:  

-   Some workloads, such as low-level monitoring or system configuration tools, may require privileged access to function properly.  
    
-   Requires careful configuration to ensure that legitimate workloads are not impacted by the restriction.  
    

Default Value: By default, Kubernetes does not allow containers to run in privileged mode unless explicitly specified. Containers must have the privileged flag set in their security context to be considered privileged.

Pre-requisites: Ensure that PodSecurityPolicies (PSPs) or another admission controller is configured to prevent privileged containers unless explicitly required by trusted workloads.

### Test Plan:

Using Azure Console:

1.  Navigate to the Azure portal and access your Azure Kubernetes Service (AKS) cluster.
    
2.  Review the Pod specifications and verify that the privileged flag is not set to true unless absolutely required.
    
3.  Check if PodSecurityPolicies or other Admission Controllers are in place to restrict the use of privileged containers.
    

Using Azure CLI:

1.  Use the following command to check for the use of privileged containers in the pod specifications:
    
     kubectl get pods --all-namespaces -o=jsonpath='{.items\[\*\].spec.securityContext.privileged}'
    
    Verify that privileged is not set to true for containers unless explicitly needed for specific workloads.
    
2.  Ensure that PodSecurityPolicy or other admission control policies are applied to restrict the use of privileged containers.
    

### Implementation Plan:

Using Azure Console:

1.  In the Azure portal, go to your AKS cluster and access the Pod specifications.  
    

Modify the security context of containers to disable the privileged flag:

securityContext:
  privileged: false

Apply a PodSecurityPolicy (or similar admission control mechanism) to restrict the use of privileged containers. A sample PodSecurityPolicy might look like:

apiVersion: policy/v1beta1
kind: PodSecurityPolicy
metadata:
  name: restrict-privileged-containers
spec:
  privileged: false

Ensure that this policy is applied and enforced through RBAC and Kubernetes Admission Control.  

Using Azure CLI:

Modify the Pod specification to disable the privileged flag:

securityContext:
  privileged: false

Apply the updated Pod configuration:

 kubectl apply -f pod-spec.yaml

Create a PodSecurityPolicy that restricts the use of privileged containers:

apiVersion: policy/v1beta1
kind: PodSecurityPolicy
metadata:
  name: restrict-privileged-containers
spec:
  privileged: false

Apply the PodSecurityPolicy using:

 kubectl apply -f pod-security-policy.yaml

### Backout Plan:

Using Azure Console:

1.  If restricting privileged containers causes issues, revert the changes in the Azure portal by allowing privileged containers for specific workloads.
    

Using Azure CLI:

Revert the Pod specification by adding the privileged flag to containers where necessary:

securityContext:
  privileged: true

Apply the updated configuration:

 kubectl apply -f pod-spec.yaml

Revert any PodSecurityPolicy changes by deleting the policy:

 kubectl delete podsecuritypolicy restrict-privileged-containers

### References:

1.  Kubernetes Security Context Documentation  
    
2.  Kubernetes PodSecurityPolicy Documentation  
    
3.  [Azure Kubernetes Service (AKS) Best Practices](https://learn.microsoft.com/en-us/azure/aks/security-best-practices)

## Related compliance guidance

- [SOC 2 compliance: a practical implementation guide for cloud-native SaaS teams](https://support.icompaas.com/compliance/soc-2-trust-services-criteria): Configuration checks like this one are the technical half of a SOC 2 / ISO 27001 programme — the guide shows where they fit, what else an auditor expects, and how to evidence them.
- [ISO/IEC 27001:2022 compliance: a practical implementation guide](https://support.icompaas.com/compliance/iso-27001-2022): ISO 27001 Annex A.8 (technological controls) is where cloud hardening evidence lands; the guide shows how to run the ISMS around it.