Microsoft Defender for Cloud · Azure Kubernetes Service
Containers sharing sensitive host namespaces should be avoided
Written and reviewed by Emnode · Last reviewed
What does the recommendation "Containers sharing sensitive host namespaces should be avoided" check?
Flags AKS pods whose containers request the host process ID namespace (hostPID: true) or the host inter-process communication namespace (hostIPC: true), which lets a container see and signal every process on the node and share its shared-memory segments. The check is enforced through the Azure Policy add-on for AKS and its Gatekeeper engine, so it only evaluates clusters where that add-on is installed. It inspects the pod spec, not running behaviour: it does not catch a container that escapes isolation through a kernel exploit, an over-broad Linux capability such as SYS_PTRACE, or a privileged: true flag, and it does not by itself govern hostNetwork or host path mounts, which are separate hardening controls.
Why does "Containers sharing sensitive host namespaces should be avoided" matter?
A pod that shares the host PID namespace can read another tenant's command-line arguments and environment, trace processes, and send signals to kill or stall workloads on the same node, including the kubelet. Sharing the host IPC namespace exposes shared memory used by other pods and host daemons, a common path to leaking secrets between workloads that were meant to be isolated. Both turn a single compromised container into a foothold on the whole node rather than a contained incident, widening the blast radius of any application vulnerability and undermining the multi-tenant separation most AKS clusters depend on. For a regulated workload that can be the difference between an isolated bug and a reportable breach.
How do I fix "Containers sharing sensitive host namespaces should be avoided"?
- Remove hostPID and hostIPC from the pod spec (or set both to false) for every workload that does not have a documented need to share node namespaces, then redeploy; the vast majority of application pods never require either.
- Install and enable the Azure Policy add-on so the cluster can audit and block future violations: az aks enable-addons --addons azure-policy --name <cluster> --resource-group <rg>. Register the provider first if needed with az provider register --namespace Microsoft.PolicyInsights.
- Assign the built-in policy 'Kubernetes cluster containers should not share host namespaces' in Deny mode by looking up its ID rather than hardcoding it: pid=$(az policy definition list --query "[?displayName=='Kubernetes cluster containers should not share host namespaces'].name" -o tsv); az policy assignment create --name aks-no-host-namespaces --policy "$pid" --scope <cluster-resource-id>. Start in Audit to find offenders, then switch the effect to Deny once they are remediated.
Remediation script · bash
# 1. Turn on the Azure Policy add-on so Gatekeeper starts auditing the cluster.
az provider register --namespace Microsoft.PolicyInsights
az aks enable-addons --addons azure-policy \
--resource-group rg-prod --name aks-prod
# Confirm the policy and gatekeeper pods are running.
kubectl get pods -n kube-system -l app=azure-policy
kubectl get pods -n gatekeeper-system
# 2. Assign the built-in pod security baseline initiative in AUDIT first.
# Look the initiative up by its exact display name, never paste a GUID.
SCOPE=$(az aks show -g rg-prod -n aks-prod --query id -o tsv)
SETID=$(az policy set-definition list \
--query "[?displayName=='Kubernetes cluster pod security baseline standards for Linux-based workloads'].name" -o tsv)
az policy assignment create \
--name aks-pod-baseline \
--policy-set-definition "$SETID" \
--scope "$SCOPE" \
--params '{"effect":{"value":"audit"},"excludedNamespaces":{"value":["kube-system","gatekeeper-system","azure-arc"]}}'
# 3. Fix the workloads (in each pod spec, securityContext):
# privileged: false | runAsNonRoot: true | runAsUser: 1000
# allowPrivilegeEscalation: false | readOnlyRootFilesystem: true
# capabilities: { drop: ["ALL"] } and add back only what is needed.
# 4. Once audit is clean except for named exceptions, ENFORCE.
az policy assignment update --name aks-pod-baseline \
--set parameters.effect.value=deny Full walkthrough (console steps, edge cases and verification) in the lesson Enforce AKS pod security.
Is "Containers sharing sensitive host namespaces should be avoided" a false positive?
A genuine node-level monitoring or debugging agent, for example a profiler or a security sensor that must observe host processes, will legitimately set hostPID: true and flag here. Keep these in a dedicated namespace, document the justification, and add that namespace to the policy assignment's excludedNamespaces so the control stays in Deny mode for everything else rather than being weakened cluster-wide.
More Azure Kubernetes Service controls
- Azure Kubernetes Service clusters should have Defender profile enabled
- Azure Kubernetes Service clusters should have the Azure Policy add-on for Kubernetes installed
- Azure running container images should have vulnerabilities resolved (powered by Microsoft Defender Vulnerability Management)
- Container CPU and memory limits should be enforced
- Container images should be deployed from trusted registries only
- Container with privilege escalation should be avoided
- Diagnostic logs in Kubernetes services should be enabled
- Immutable (read-only) root filesystem should be enforced for containers
- Kubernetes API server should be configured with restricted access
- Kubernetes clusters should be accessible only over HTTPS
- Kubernetes clusters should disable automounting API credentials
- Kubernetes clusters should not use the default namespace