Skip to main content

More Info:

Use namespaces to isolate your Kubernetes objects.

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)
  • 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. 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).
  2. 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
    • Note which existing workloads in default or other shared namespaces should move into their own dedicated namespace(s).
  3. Check for objects incorrectly living in shared/default namespaces
    • List objects in default and any “catch-all” namespaces:
    • Flag any non-platform, business workloads in kube-system (they should usually be moved) and any critical production workloads in default (they typically deserve dedicated namespaces).
  4. 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.
  5. Plan and migrate workloads into appropriate namespaces
    • For each workload identified in step 3, update its manifests to set metadata.namespace to 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:
  6. Verify namespace-based boundaries are in place
    • Confirm namespaces and workload placement:
    • Ensure that the default namespace no longer hosts critical or multi-tenant workloads and that each major application/team/environment has a clearly defined namespace boundary.
What to look for (possible problems)
  • Only default, kube-system, kube-public, and kube-node-lease exist, but many applications/workloads are running → suggests everything is in default with no boundaries.
  • A single custom namespace (e.g., prod) containing all non-system workloads for different teams/environments → coarse boundary, little separation.

What to look for (possible problems)
  • Most or all Deployments/Pods/Services are in the default namespace.
  • Critical system-like components or third-party platforms (logging, monitoring, CI agents) running in default rather than a dedicated namespace.
  • Mixed environments (dev, test, prod) or mixed teams using the same namespace.

What to look for (possible problems)
  • Broad, powerful RoleBindings (e.g., binding cluster-admin or 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.

What to look for (possible problems)
  • 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.

What to look for (possible problems)
  • 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=multi or a generic shared=true for 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 default that should be isolated into their own namespaces?
Explanation of what output may indicate a problem (to review manually):
  • Cluster namespaces:
    • Only default, kube-system, kube-public, kube-node-lease plus all workloads running in default may indicate missing administrative boundaries.
  • Namespaces by label:
    • Namespaces with (no-team) / (no-env) suggest lack of ownership and unclear separation.
  • Workloads per namespace:
    • Many unrelated applications co-located in the same namespace (especially default) indicate weak isolation.
  • ClusterRoles and ClusterRoleBindings:
    • Very broad cluster-wide roles (e.g., custom *admin* roles) bound to many subjects reduce the effectiveness of namespace boundaries.
  • 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 namespace and Namespaces without any NetworkPolicy:
    • Critical or multi-tenant namespaces with no NetworkPolicies likely have no network-level isolation between tenants or apps.

Additional Reading: