More Info:
Placing resources in the default namespace prevents applying tailored policies and RBAC boundaries. New resources should be created in specific, purpose-built namespaces.Risk Level
LowAddress
SecurityCompliance Standards
- CIS GKE
Triage and Remediation
- Remediation
Remediation
Manual Steps
Manual Steps
-
List all non-system workloads in the default namespace
- Run on: any machine with kubectl access
-
Decide target namespaces and create them if needed
- Run on: any machine with kubectl access
- Replace
team-a,team-bwith meaningful names for your org:
- Repeat as required for each logical application/team boundary.
-
For each non-system resource in
default, export its manifest and re‑create it in the correct namespace- Run on: any machine with kubectl access
- Example for a deployment
myappyou want inteam-a:
- Use the same pattern for other types (e.g.,
svc,statefulset,daemonset,job,cronjob), adjusting the kind and name:
-
For workloads that must remain cluster-scoped or in
kube-system, do not move them- Run on: any machine with kubectl access
- Before moving anything, confirm it is not a core component:
- If you are unsure whether an object in
defaultis application-specific or required by an addon, consult your platform documentation or application owners before moving it.
-
Update CI/CD, Helm values, and manifests so new resources are not created in
default- In all deployment manifests, ensure either:
metadata.namespace: <desired-namespace>is set, or- You deploy with an explicit namespace flag, for example:
- For Helm charts, set a non-default namespace:
- In all deployment manifests, ensure either:
-
Verification: confirm the default namespace has no non-system resources
- Run on: any machine with kubectl access
Using kubectl
Using kubectl
On any machine with kubectl access:Edit both files:
- List what is currently in the default namespace (for planning and decisions):
- Create purpose-specific namespaces (example:
team-aandplatform):
- For each workload in
default, re-create it in an appropriate namespace. Example for a deployment and service currently in default:
metadata.namespace and any references before applying):- Change
metadata.namespace: defaulttometadata.namespace: team-a - Remove cluster-assigned fields (
status,metadata.resourceVersion,metadata.uid,metadata.creationTimestamp,metadata.managedFields) and anyownerReferencesthat no longer apply.
- After new workloads are running in non-default namespaces and you have validated functionality, delete objects from the default namespace (except the
kubernetesservice):
-
Update your workflows so new resources are not created in
default, for example by always specifying-n <namespace>ormetadata.namespacein manifests, and by configuring tooling defaults. - Verification (same logic as the audit):
Automation
Automation

