Profile Applicability:
• Level 1
Description:
Containers should generally not be allowed to run with the hostPID flag set to true. Allowing containers to share the host’s Process ID (PID) namespace can enable the container to access processes running outside the container. This capability, in combination with ptrace access, can be exploited for privilege escalation and security risks.
Rationale:
Containers running with the hostPID flag set to true can view and interact with processes running on the host. This can result in unauthorized access or manipulation of host processes, increasing the risk of container breakout and privilege escalation. This flag should only be used when necessary, and an admission control policy should be enforced to restrict containers from sharing the host PID namespace unless explicitly required.
Impact:
Pros:
Reduces the risk of containers being able to interact with or inspect processes running outside their own environment.
Prevents unnecessary security vulnerabilities related to host process exposure.
Cons:
Some use cases, such as monitoring tools or system-level containers, may require the hostPID flag. These containers should be managed separately and allowed only under specific security policies.
Default Value:
By default, Kubernetes does not restrict containers from running with the hostPID flag set to true.
Pre-requisites:
Access to the Kubernetes cluster with sufficient privileges to define and enforce pod security policies (PSPs).
Understanding of workloads that require the hostPID flag for functionality.
Remediation
Test Plan:
Using AWS Console:
Review the Pod Security Policies (PSPs) applied to each namespace to ensure that hostPID containers are not admitted without a specific policy.
Check the current pod configurations for the hostPID flag to verify that no unauthorized containers are sharing the host PID namespace.
Using AWS CLI:
Search for any pods that are running with hostPID: true by executing the following command:
kubectl get pods --all-namespaces -o json | jq -r '.items[] | select(.spec.hostPID == true) | "\(.metadata.namespace)/\(.metadata.name)"'
Alternatively, filter out pods running in namespaces other than "kube-system":
kubectl get pods --all-namespaces -o json | jq '.items[] | select(.metadata.namespace != "kube-system" and .spec.hostPID == true) | {pod: .metadata.name, namespace: .metadata.namespace, container: .spec.containers[].name}'
Review the output and ensure no unauthorized pods are sharing the host PID namespace.
Implementation Plan
Using AWS Console:
Add policies to each namespace in the cluster with user workloads to restrict the admission of hostPID containers.
Use Pod Security Admission (PSA) to enforce policies that prevent containers from running with hostPID: true.
If necessary, create exceptions for specific namespaces or service accounts that require hostPID containers, ensuring they are tightly controlled and audited.
Using AWS CLI:
Label namespaces with the restricted policy to prevent the creation of hostPID containers:
kubectl label --overwrite ns NAMESPACE podsecurity.kubernetes.io/enforce=restricted
Optionally, you can label all namespaces to enforce the policy:
kubectl label --overwrite ns --all podsecurity.kubernetes.io/enforce=restricted
Ensure that only specific namespaces or service accounts with valid use cases for hostPID containers are given exemptions.
Backout Plan
Using AWS Console:
If the policy causes issues, revert the changes by removing the enforced label:
If containers must use hostPID, restore the previous settings for the affected namespaces or workloads that need this capability.
Using AWS CLI:
Revert the changes by removing the enforced policy
kubectl label --overwrite ns NAMESPACE podsecurity.kubernetes.io/enforce=""
Allow hostPID containers only where necessary and restore the previous configurations for any critical workloads that require it.