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
LowAddress
SecurityCompliance 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
Remediation
Manual Steps
Manual Steps
-
List all resources currently in the
defaultnamespace (any machine with kubectl access) -
Decide target namespaces and create them if needed (any machine with kubectl access)
Replaceteam-a,team-bwith your chosen names.Review and map each object fromdefaultto an appropriate namespace based on application/tenant/owner. -
Export manifests of objects in
defaultand 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: defaultto the desired namespace (e.g.team-a). - Confirm that any
RoleBindingsubjects or role references still make sense in the new namespace.
- Change
-
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 fromdefault:Be careful not to delete the built‑inkubernetesservice; the above command omits it because it is a cluster‑scoped service and not usually listed with--all, but verify before confirming any deletions. -
Ensure new workloads are not created in
defaultgoing forward (any machine with kubectl access)- Update CI/CD pipelines and manifests to include
metadata.namespace: <target-namespace>or use--namespacein kubectl/Helm commands. - Optionally create an
LimitRange/ResourceQuotaor anAdmissionPolicy/ValidatingWebhook(if available in your environment) that rejects new non‑system objects in thedefaultnamespace.
- Update CI/CD pipelines and manifests to include
-
Verification (any machine with kubectl access)
Confirm the output is:
Using kubectl
Using kubectl
On any machine with kubectl access:Example for a Service:(For Services, review (Requires Gatekeeper and a matching ConstraintTemplate already installed; adjust to your admission controller or omit if not in use.)
- Identify what is using the default namespace
- Create a dedicated namespace (example:
team-a)
- Recreate workload resources in the new namespace
(Deployments, StatefulSets, DaemonSets, Jobs, CronJobs, Services, Ingresses, etc.)
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.- Delete migrated resources from the default namespace
Run only after confirming workloads are healthy in the new namespace:
- (Optional) Apply a deny policy to prevent future use of the default namespace (Kubernetes with Gatekeeper example)
- Verification (matches the audit logic)
Automation
Automation

