Microsoft Defender for Cloud · Azure Kubernetes Service
Kubernetes clusters should not use the default namespace
Written and reviewed by Emnode · Last reviewed
What does the recommendation "Kubernetes clusters should not use the default namespace" check?
Flags AKS clusters that allow ConfigMaps, Pods, Secrets, Services or ServiceAccounts to be created in the built-in 'default' namespace. It is enforced through the Azure Policy add-on for Kubernetes, which projects the assignment into the cluster as a Gatekeeper admission constraint, so the cluster must have that add-on installed and reporting compliance for the check to evaluate at all. The control only governs those five resource types in 'default'; it does not touch the 'kube-system' or 'kube-public' namespaces, does not validate what is deployed inside the named namespaces you do create, and does not by itself author or apply Kubernetes RBAC. The recommendation is audit-only by default, so it reports drift until you raise the effect to Deny.
Why does "Kubernetes clusters should not use the default namespace" matter?
The default namespace ships with permissive, cluster-wide expectations: teams drop workloads there to move fast, and over time it accumulates a flat pile of Pods and Secrets that no NetworkPolicy, resource quota or RBAC binding cleanly isolates. A compromised or buggy workload sitting in 'default' can then read neighbouring Secrets or reach Services that should have been segmented, turning a single bad container into lateral movement across the cluster. Because nothing in 'default' carries a meaningful ownership label, it is also the namespace least likely to be monitored, quota-capped or cleanly torn down, so abandoned test workloads linger there as standing attack surface. Forcing every workload into a named namespace gives each team a blast-radius boundary you can attach policy, quotas and least-privilege access to, which is the difference between one contained incident and an estate-wide one, and it makes cost, ownership and audit reporting tractable per team.
How do I fix "Kubernetes clusters should not use the default namespace"?
- Enable the Azure Policy add-on so the constraint can be enforced: az aks enable-addons --addons azure-policy --name <cluster> --resource-group <rg>. In Bicep, set the 'azurepolicy' add-on profile to enabled on the managedClusters resource.
- Assign the built-in policy by its exact display name rather than a pasted GUID, then set the effect to Deny so new objects in 'default' are rejected: pid=$(az policy definition list --query "[?displayName=='Kubernetes clusters should not use the default namespace'].name" -o tsv); az policy assignment create --name aks-no-default-ns --policy "$pid" --scope <cluster-resource-id> --params '{"effect":{"value":"Deny"}}'.
- Migrate existing workloads into purpose-built namespaces (kubectl create namespace <team>, then redeploy manifests with that namespace set) and bake the namespace into your Helm or Kustomize templates so nothing lands in 'default' again.
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 "Kubernetes clusters should not use the default namespace" a false positive?
Cluster-bootstrap and add-on components that Microsoft installs sometimes need objects outside named team namespaces, and a small number of platform tools legitimately read from 'default'. The policy lets you carve these out with its 'excludedNamespaces' and 'labelSelector' parameters, so add the specific exclusions you have reviewed rather than dropping the effect to Disabled, which would silently reopen 'default' for everyone.
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
- Containers sharing sensitive host namespaces 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