Skip to main content

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

Low

Address

Security

Compliance Standards

  • CIS GKE

Triage and Remediation

Remediation

Manual Steps

  1. List all non-system workloads in the default namespace
    • Run on: any machine with kubectl access
  2. Decide target namespaces and create them if needed
    • Run on: any machine with kubectl access
    • Replace team-a, team-b with meaningful names for your org:
    • Repeat as required for each logical application/team boundary.
  3. 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 myapp you want in team-a:
    • Use the same pattern for other types (e.g., svc, statefulset, daemonset, job, cronjob), adjusting the kind and name:
  4. 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 default is application-specific or required by an addon, consult your platform documentation or application owners before moving it.
  5. 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:
  6. Verification: confirm the default namespace has no non-system resources
    • Run on: any machine with kubectl access
On any machine with kubectl access:
  1. List what is currently in the default namespace (for planning and decisions):
  1. Create purpose-specific namespaces (example: team-a and platform):
  1. For each workload in default, re-create it in an appropriate namespace. Example for a deployment and service currently in default:
Export manifests (edit to adjust metadata.namespace and any references before applying):
Edit both files:
  • Change metadata.namespace: default to metadata.namespace: team-a
  • Remove cluster-assigned fields (status, metadata.resourceVersion, metadata.uid, metadata.creationTimestamp, metadata.managedFields) and any ownerReferences that no longer apply.
Then apply in the target namespace:
  1. After new workloads are running in non-default namespaces and you have validated functionality, delete objects from the default namespace (except the kubernetes service):
  1. Update your workflows so new resources are not created in default, for example by always specifying -n <namespace> or metadata.namespace in manifests, and by configuring tooling defaults.
  2. Verification (same logic as the audit):