Minimize The Admission Of Containers Sharing The Host Process ID Namespace

More Info:

Containers sharing the host PID namespace can view and interact with all processes on the node. Their admission should be restricted via Pod Security Admission policies.

Risk Level

High

Address

Security

Compliance Standards

• CIS AKS

Triage and Remediation

Remediation

Remediation

Manual Steps

1. Identify pods using hostPID across all namespaces
   Run on: any machine with kubectl access

   kubectl get pods --all-namespaces -o jsonpath='{range .items[?(@.spec.hostPID==true)]}{.metadata.namespace}{"\t"}{.metadata.name}{"\n"}{end}'
   

   Save the list and, for each pod found, inspect who runs it and why:

   kubectl get pod POD_NAME -n NAMESPACE -o yaml
   

2. Decide which workloads (if any) truly require hostPID
   For each pod with hostPID: true, review its purpose with the owning team (e.g., node monitoring/diagnostics agents may have a requirement; most app workloads do not).

   • If hostPID is not strictly required, plan to remove it from the pod spec.
   • If it is required, note the namespace, pod name, and service account for later RBAC tightening:
     kubectl get pod POD_NAME -n NAMESPACE -o jsonpath='{.spec.serviceAccountName}{"\n"}'
     

3. Harden namespaces with Pod Security Admission labels
   Decide which namespaces must be strictly protected (no hostPID allowed) and which, if any, can host exceptional workloads.

   • To enforce restricted (disallowing hostPID) on a namespace:
     kubectl label --overwrite ns NAMESPACE pod-security.kubernetes.io/enforce=restricted
     
   • To enable baseline warnings cluster-wide (helps detect issues without blocking):
     kubectl label --overwrite ns --all pod-security.kubernetes.io/warn=baseline
     

   Avoid placing hostPID-dependent workloads into restricted namespaces.

4. Tighten RBAC for namespaces that legitimately use hostPID
   For any namespace that truly needs hostPID, ensure only a dedicated service account can create such pods:

   • Identify who can create pods now:
     kubectl auth can-i create pods --as USER_OR_SA -n NAMESPACE
     kubectl get role,rolebinding,clusterrole,clusterrolebinding -n NAMESPACE
     
   • Based on this output, reduce create/update permissions on pods so that only the specific service account(s) used by the approved hostPID workloads retain that ability.

5. Refactor or remove non-essential hostPID usage
   For pods where hostPID is not required, update their manifests or Helm charts to remove hostPID: true from .spec and re-deploy. Use your normal deployment mechanism (kubectl apply, GitOps, or Helm) and ensure that application behavior remains correct without host PID access.

6. Verify the policy and current state
   Run on: any machine with kubectl access

   • Confirm no remaining hostPID pods except in approved namespaces:
     kubectl get pods --all-namespaces -o jsonpath='{range .items[?(@.spec.hostPID==true)]}{.metadata.namespace}{"\t"}{.metadata.name}{"\n"}{end}'
     
   • Confirm Pod Security Admission labels are set as intended:
     kubectl get ns --show-labels
     
   • Optionally, attempt to create a test pod with hostPID: true in a restricted namespace and ensure it is rejected.

Using kubectl

Using kubectl

1. List pods that request hostPID: true

Run on: any machine with kubectl access.

kubectl get pods -A -o=jsonpath='{range .items[?(@.spec.hostPID==true)]}{.metadata.namespace}{"\t"}{.metadata.name}{"\n"}{end}'

Problem indication:

• Any line of output means that pod is running with hostPID: true and must be manually reviewed to confirm if this is strictly necessary.

For more detail on those pods:

kubectl get pods -A \
  -o custom-columns='NAMESPACE:.metadata.namespace,NAME:.metadata.name,HOSTPID:.spec.hostPID'

2. Inspect a specific pod’s spec

For each pod identified above:

kubectl get pod POD_NAME -n NAMESPACE -o yaml

Problem indication:

• spec.hostPID: true without a clear, documented operational need.
• Pods using default service accounts or broadly scoped service accounts when hostPID: true is set.

3. Check Pod Security Admission labels on namespaces

List PSA labels for all namespaces:

kubectl get ns \
  -o custom-columns='NAME:.metadata.name,ENFORCE:.metadata.labels.pod-security\.kubernetes\.io/enforce,WARN:.metadata.labels.pod-security\.kubernetes\.io/warn' \
  | sort

Problem indication:

• Namespaces lacking pod-security.kubernetes.io/enforce=restricted where hostPID should generally be disallowed.
• Sensitive or multi-tenant namespaces with ENFORCE unset or set to privileged/baseline.
• Namespaces allowing hostPID but not clearly segregated for that purpose.

To inspect labels for a single namespace:

kubectl get ns NAMESPACE --show-labels

4. Review RBAC for namespaces that legitimately need hostPID

First, list service accounts in a namespace that is allowed to use hostPID:

kubectl get sa -n NAMESPACE

Then list rolebindings and clusterrolebindings referencing those service accounts:

kubectl get rolebinding,clusterrolebinding -A -o yaml | grep -B5 -A10 "kind: ServiceAccount"

Problem indication:

• Service accounts used by hostPID pods are bound to roles that are overly broad or reused widely across other workloads.
• No clear, dedicated service account for hostPID workloads (e.g., using default service account).

Automation

#!/usr/bin/env bash
# Report use of hostPID and Pod Security Admission labels across all namespaces.
# Run on: any machine with kubectl access and current context set.

set -euo pipefail

echo "=== Pod Security Admission labels per namespace ==="
kubectl get ns \
  -o custom-columns=NAME:.metadata.name,ENFORCE:.metadata.labels.pod-security\\.kubernetes\\.io/enforce,WARN:.metadata.labels.pod-security\\.kubernetes\\.io/warn \
  | sed 's/<none>//g'

cat <<'EOF'

Interpretation:
- ENFORCE=restricted: namespace is enforcing restricted Pod Security level (good).
- ENFORCE missing or set to baseline/privileged: hostPID is more likely to be allowed (review).
- WARN=baseline (or other): only warnings are emitted; enforcement still depends on ENFORCE.

Namespaces without ENFORCE=restricted should be reviewed, especially if they are not
intended for privileged workloads.

EOF

echo "=== Pods using hostPID=true (all namespaces) ==="
kubectl get pods --all-namespaces -o json \
  | jq -r '
    .items[]
    | {
        ns: .metadata.namespace,
        pod: .metadata.name,
        hostPID: .spec.hostPID,
        sa: .spec.serviceAccountName
      }
    | select(.hostPID == true)
    | "\(.ns)\t\(.pod)\t\(.sa)\t\(.hostPID)"' \
  | awk 'BEGIN { print "NAMESPACE\tPOD\tSERVICEACCOUNT\tHOSTPID" }1'

cat <<'EOF'

Interpretation:
- Any line listed here is a pod that has hostPID=true.
- For each such pod, verify:
  - The namespace is expected to allow hostPID.
  - The namespace has Pod Security Admission labels intentionally set (or intentionally absent).
  - The SERVICEACCOUNT is tightly scoped via RBAC and not used broadly.

Potential problems:
- Namespaces that are not critical/privileged but have pods with HOSTPID=true.
- Namespaces without ENFORCE=restricted that do not have a clear operational need
  for looser policies.
- Service accounts used by hostPID pods that are shared with other workloads.

EOF

Problem indicators in the script output:

• Any non-system namespace (or any namespace you do not explicitly trust for privileged workloads) that:
  • Lacks ENFORCE=restricted, and/or
  • Contains pods listed with HOSTPID=true.
• Service accounts shown in the hostPID list that are also used widely by non-privileged pods.