More Info:
Use namespaces to isolate your Kubernetes objects.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)
- 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
-
Inventory existing namespaces and workloads
- Run (on any machine with kubectl access):
- Identify which applications, teams, and environments (dev/test/stage/prod) currently share a namespace (especially
default).
- Run (on any machine with kubectl access):
-
Identify isolation requirements and desired boundaries
- With your application/ops teams, decide how you want to separate:
- By environment: e.g.
dev,stage,prod - By team or business unit: e.g.
payments,analytics - By application: e.g.
web-frontend,orders-service
- By environment: e.g.
- Note which existing workloads in
defaultor other shared namespaces should move into their own dedicated namespace(s).
- With your application/ops teams, decide how you want to separate:
-
Check for objects incorrectly living in shared/default namespaces
- List objects in
defaultand any “catch-all” namespaces: - Flag any non-platform, business workloads in
kube-system(they should usually be moved) and any critical production workloads indefault(they typically deserve dedicated namespaces).
- List objects in
-
Design and create the required namespaces
- Define the namespaces you need (from step 2), including labels/annotations for ownership and environment.
- Create them:
- Adjust names and labels to match your chosen scheme.
-
Plan and migrate workloads into appropriate namespaces
- For each workload identified in step 3, update its manifests to set
metadata.namespaceto the new target namespace and adjust any in-namespace references (ConfigMaps, Secrets, Services, RoleBindings, NetworkPolicies, etc.). - Apply the updated manifests:
- Decommission the old objects from the previous namespace once the new ones are verified:
- For each workload identified in step 3, update its manifests to set
-
Verify namespace-based boundaries are in place
- Confirm namespaces and workload placement:
- Ensure that the
defaultnamespace no longer hosts critical or multi-tenant workloads and that each major application/team/environment has a clearly defined namespace boundary.
- Confirm namespaces and workload placement:
Using kubectl
Using kubectl
- Only
default,kube-system,kube-public, andkube-node-leaseexist, but many applications/workloads are running → suggests everything is indefaultwith no boundaries. - A single custom namespace (e.g.,
prod) containing all non-system workloads for different teams/environments → coarse boundary, little separation.
- Most or all Deployments/Pods/Services are in the
defaultnamespace. - Critical system-like components or third-party platforms (logging, monitoring, CI agents) running in
defaultrather than a dedicated namespace. - Mixed environments (dev, test, prod) or mixed teams using the same namespace.
- Broad, powerful RoleBindings (e.g., binding
cluster-adminor wide-scoped roles) applied in a namespace that mixes unrelated workloads. - Lack of any RoleBindings in non-system namespaces when multiple teams share the cluster, suggesting no real separation of administrative duties.
- Many unrelated applications, teams, or environments all running in
default. - No labels/annotations that indicate intended ownership, environment, or purpose, making it hard to enforce policies and boundaries.
- No labeling strategy (e.g., no
team=...,env=...,app=...), making it unlikely namespaces are being used as deliberate administrative boundaries. - One namespace with labels suggesting it serves multiple distinct environments or teams (e.g.,
env=multior a genericshared=truefor many unrelated workloads).
Use the above outputs to answer, manually:
- Are applications grouped into namespaces by environment, team, or function?
- Are high-privilege permissions granted in namespaces that carry mixed or unrelated workloads?
- Are there workloads still running in
defaultthat should be isolated into their own namespaces?
Automation
Automation
Cluster namespaces:- Only
default,kube-system,kube-public,kube-node-leaseplus all workloads running indefaultmay indicate missing administrative boundaries.
- Only
Namespaces by label:- Namespaces with
(no-team)/(no-env)suggest lack of ownership and unclear separation.
- Namespaces with
Workloads per namespace:- Many unrelated applications co-located in the same namespace (especially
default) indicate weak isolation.
- Many unrelated applications co-located in the same namespace (especially
ClusterRoles and ClusterRoleBindings:- Very broad cluster-wide roles (e.g., custom
*admin*roles) bound to many subjects reduce the effectiveness of namespace boundaries.
- Very broad cluster-wide roles (e.g., custom
RoleBindings that bind to ClusterRoles:- Numerous rolebindings to powerful ClusterRoles in many namespaces show that namespace boundaries are being bypassed by cluster-scoped permissions.
ServiceAccounts used by Pods:- Heavy reuse of the same high-privilege ServiceAccount across multiple namespaces/apps weakens separation.
NetworkPolicies per namespaceandNamespaces without any NetworkPolicy:- Critical or multi-tenant namespaces with no NetworkPolicies likely have no network-level isolation between tenants or apps.

