Skip to main content

More Info:

Kubernetes provides a default namespace, where objects are placed if no namespace is specified for them. Placing objects in this namespace makes application of RBAC and other controls more difficult.

Risk Level

Low

Address

Security

Compliance Standards

  • APRA CPS 234 (Australia)
  • BSI C5 (Germany)
  • Brazil LGPD
  • CCPA / CPRA (California)
  • CIS Critical Security Controls v8
  • CIS GKE
  • CMMC 2.0
  • CSA Cloud Controls Matrix v4
  • DPDPA
  • Digital Operational Resilience Act (EU)
  • Essential 8
  • ISO/IEC 27017
  • ISO/IEC 27018
  • ISO/IEC 27701
  • KSA PDPL
  • MAS Technology Risk Management (Singapore)
  • MITRE ATT&CK (Cloud)
  • NIS2 Directive
  • NIST SP 800-171
  • NYDFS 23 NYCRR 500
  • SWIFT Customer Security Controls Framework
  • Sarbanes-Oxley IT General Controls
  • UK NCSC Cyber Assessment Framework

Triage and Remediation

Remediation

Manual Steps

  1. List all resources currently in the default namespace (any machine with kubectl access)
  2. Decide target namespaces and create them if needed (any machine with kubectl access)
    Replace team-a, team-b with your chosen names.
    Review and map each object from default to an appropriate namespace based on application/tenant/owner.
  3. Export manifests of objects in default and edit to use the new namespace(s) (any machine with kubectl access)
    Example for all standard workload resources:
    Open the file and for each object:
    • Change metadata.namespace: default to the desired namespace (e.g. team-a).
    • Confirm that any RoleBinding subjects or role references still make sense in the new namespace.
  4. Recreate resources in the proper namespaces and delete them from default (any machine with kubectl access)
    Apply edited manifests:
    Once workloads are healthy in the new namespaces, delete resources from default:
    Be careful not to delete the built‑in kubernetes service; the above command omits it because it is a cluster‑scoped service and not usually listed with --all, but verify before confirming any deletions.
  5. Ensure new workloads are not created in default going forward (any machine with kubectl access)
    • Update CI/CD pipelines and manifests to include metadata.namespace: <target-namespace> or use --namespace in kubectl/Helm commands.
    • Optionally create an LimitRange/ResourceQuota or an AdmissionPolicy/ValidatingWebhook (if available in your environment) that rejects new non‑system objects in the default namespace.
  6. Verification (any machine with kubectl access)
    Confirm the output is:
On any machine with kubectl access:
  1. Identify what is using the default namespace
  1. Create a dedicated namespace (example: team-a)
  1. Recreate workload resources in the new namespace
    (Deployments, StatefulSets, DaemonSets, Jobs, CronJobs, Services, Ingresses, etc.)
Example for a Deployment:
Example for a Service:
(For Services, review clusterIP handling manually; do not blindly apply to production without checking type/annotations.)Repeat for all non‑system resources currently in default. Update any references (e.g., RoleBindings, NetworkPolicies, Ingress host/rules, external clients) to point to the new namespace.
  1. Delete migrated resources from the default namespace
    Run only after confirming workloads are healthy in the new namespace:
  1. (Optional) Apply a deny policy to prevent future use of the default namespace (Kubernetes with Gatekeeper example)
(Requires Gatekeeper and a matching ConstraintTemplate already installed; adjust to your admission controller or omit if not in use.)
  1. Verification (matches the audit logic)