Profile Applicability:
• Level 1
Description:
Privileged containers, defined by the securityContext.privileged flag being set to true, should not be allowed in the cluster unless absolutely necessary. These containers have unrestricted access to all Linux Kernel capabilities and devices, which can pose serious security risks if misused. Admission control policies should be in place to prevent the creation of privileged containers unless a specific exception is required.
Rationale:
Privileged containers can perform actions that the host system can do, such as manipulating the network stack or accessing sensitive devices. The ability to run containers in this mode should be strictly controlled. There should be at least one admission control policy that does not permit privileged containers. Privileged containers should only be allowed under strict conditions and should be limited to certain users or service accounts with explicit permissions.
Impact:
Pros:
Reduces the risk of privilege escalation through containers.
Prevents unauthorized containers from running with elevated privileges.
Ensures better control over the types of containers that can run in the cluster.
Cons:
Some use cases, such as network manipulation or access to host devices, require privileged containers. These cases must be handled separately with careful access control.
Default Value:
By default, Kubernetes allows the creation of privileged containers with no restrictions.
Pre-requisites:
Access to the Kubernetes cluster with sufficient privileges to review and modify pod security policies (PSPs) and namespace labels.
Knowledge of the workloads that require privileged containers.
Remediation
Test Plan:
Using AWS Console:
Review the namespaces and associated policies in your cluster to ensure that privileged containers are not being admitted.
Check the current policies applied to pods using the kubectl commands provided below.
Using AWS CLI:
To find pods with privileged containers, run the following command to list the pods and filter by privileged: true:
kubectl get pods --all-namespaces -o json | jq -r '.items[] | select(.spec.containers[].securityContext.privileged == true) | .metadata.name'
Alternatively, to find specific namespaces and containers with privileged access:
kubectl get pods --all-namespaces -o json | jq '.items[] | select(.metadata.namespace != "kube-system" and .spec.containers[]?.securityContext?.privileged == true) | {pod: .metadata.name, namespace: .metadata.namespace, container: .spec.containers[].name}'
Review the output to ensure that no unauthorized privileged containers exist in the cluster.
Implementation Plan
Label namespaces with the restricted policy to ensure that privileged containers are not admitted:
kubectl label --overwrite ns NAMESPACE podsecurity.kubernetes.io/enforce=restricted
Apply the PSA to restrict privileged containers across all namespaces:
kubectl label --overwrite ns --all podsecurity.kubernetes.io/enforce=restricted
Test the policy by attempting to create privileged containers and ensuring they are blocked unless explicitly allowed by another policy.
Backout Plan
Using AWS Console:
If the new policy causes issues, revert the namespace labels to allow privileged containers by removing the enforced policy.
If a container must run with privileged access, ensure it is assigned to the appropriate service account and that the necessary policies are in place for it to be allowed.
Using AWS CLI:
Revert the namespace label changes by removing the enforced policy:
kubectl label --overwrite ns NAMESPACE podsecurity.kubernetes.io/enforce=""
If needed, re-enable privileged containers for specific namespaces or workloads that require it.