Skip to main content

Minimize The Admission Of Containers Sharing The Host

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​

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.