> ## Documentation Index
> Fetch the complete documentation index at: https://cloudanix.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# The Default Namespace Should Not Be Used

### More Info:

Placing resources in the default namespace makes it harder to apply access controls and segregation. Create dedicated namespaces and create all new resources within a specific namespace.

### Risk Level

Low

### Address

Security

### Compliance Standards

* CIS OKE

### Triage and Remediation

<Tabs>
  <Tab title="Remediation">
    ### Remediation

    <AccordionGroup>
      <Accordion title="Manual Steps" defaultOpen="true">
        1. **Identify all resources currently in the `default` namespace**
           * Run on: any machine with kubectl access
           * Command:
             ```bash theme={null}
             kubectl api-resources --verbs=list --namespaced -o name \
               | xargs -n1 kubectl get -n default --ignore-not-found
             ```
           * Review which workloads, services, and other objects are using `default` and group them logically by application/team/environment.

        2. **Decide target namespaces and create them if needed**
           * For each logical group identified in step 1, decide a dedicated namespace name (e.g. `team-a-prod`, `payments`, `logging`).
           * Create missing namespaces:
             ```bash theme={null}
             kubectl create namespace team-a-prod
             kubectl create namespace payments
             # ...repeat as required
             ```

        3. **Plan RBAC and policy for the new namespaces**
           * For each new namespace, define who should access it and at what level (view, edit, admin).
           * Example (adjust subjects and roles before applying):
             ```bash theme={null}
             kubectl apply -f - <<'EOF'
             apiVersion: rbac.authorization.k8s.io/v1
             kind: RoleBinding
             metadata:
               name: team-a-admins
               namespace: team-a-prod
             subjects:
             - kind: Group
               name: team-a
               apiGroup: rbac.authorization.k8s.io
             roleRef:
               kind: ClusterRole
               name: admin
               apiGroup: rbac.authorization.k8s.io
             EOF
             ```
           * Similarly review any NetworkPolicies, ResourceQuotas, PodSecurity policies/levels, etc., and prepare equivalents per namespace.

        4. **Migrate workloads and supporting resources from `default` to the chosen namespaces**
           * Export each object from `default`, edit `metadata.namespace`, and re-create it in the target namespace:
             ```bash theme={null}
             # Example for a single deployment
             kubectl get deployment my-app -n default -o yaml > /tmp/my-app.yaml
             sed -i 's/namespace: default/namespace: team-a-prod/' /tmp/my-app.yaml
             # Remove fields not valid on create
             yq eval 'del(.metadata.uid, .metadata.resourceVersion, .metadata.creationTimestamp, .status)' -i /tmp/my-app.yaml
             kubectl delete deployment my-app -n default
             kubectl apply -f /tmp/my-app.yaml
             ```
           * Repeat for Services, ConfigMaps, Secrets, Jobs/CronJobs, Ingresses, etc.
           * For workloads created by higher-level tools (Helm, GitOps, operators), update those tools’ configuration to deploy into the chosen namespaces instead of `default`.

        5. **Prevent new workloads from accidentally landing in `default`**
           * Update CI/CD, Helm values, Kustomize overlays, and any scripts to always set `metadata.namespace` explicitly or use `--namespace` in kubectl/Helm commands.
           * Optionally, restrict use of `default` via admission controls (e.g., ValidatingAdmissionPolicy, OPA/Gatekeeper) so that new Pods/Deployments/etc. in `default` are denied unless explicitly allowed.

        6. **Verify that `default` is no longer in active use for application resources**
           * Re-run the discovery and confirm only minimal/system objects (if any) remain:
             ```bash theme={null}
             kubectl api-resources --verbs=list --namespaced -o name \
               | xargs -n1 kubectl get -n default --ignore-not-found
             ```
           * Confirm your target namespaces now hold the expected resources:
             ```bash theme={null}
             kubectl get all -A
             ```
           * Decide and document your policy on what (if anything) is allowed to remain in `default` and monitor periodically with the same commands.
      </Accordion>

      <Accordion title="Using kubectl">
        ### Using kubectl

        Run these commands from any machine with kubectl access.

        1. List resources currently in the `default` namespace

        ```bash theme={null}
        kubectl get all -n default
        ```

        Problem indication: Any non-system workloads (apps, deployments, jobs, services, etc. that are part of normal application stacks) appearing here suggest the `default` namespace is being used inappropriately.

        2. Show all resource types in the `default` namespace, including non-pod objects

        ```bash theme={null}
        kubectl api-resources --verbs=list --namespaced -o name \
          | xargs -n 1 kubectl get -n default --ignore-not-found
        ```

        Problem indication: Application-related objects (ConfigMaps, Secrets, Ingresses, RBAC bindings, etc.) in `default` indicate mixed or unclear segregation of resources.

        3. Check which contexts default to the `default` namespace

        ```bash theme={null}
        kubectl config get-contexts
        ```

        Focus on the `NAMESPACE` column.

        Problem indication: Contexts with an empty `NAMESPACE` column default to `default`. If these contexts are used by humans or automation (CI/CD), they likely create resources in `default` unless explicitly overridden.

        4. Inspect RBAC bindings tied to the `default` namespace

        ```bash theme={null}
        kubectl get rolebindings,roles -n default
        kubectl get clusterrolebindings -o wide | grep '\bdefault\b' || true
        ```

        Problem indication: Broad roles (e.g., `edit`, `admin`, or custom high-privilege roles) in the `default` namespace, or cluster role bindings referencing `default` service accounts, indicate that `default` may be carrying security-significant workloads or permissions.

        5. Identify service accounts actively used in the `default` namespace

        ```bash theme={null}
        kubectl get serviceaccounts -n default
        kubectl get pods -n default -o jsonpath='{range .items[*]}{.metadata.name}{"\t"}{.spec.serviceAccountName}{"\n"}{end}'
        ```

        Problem indication: Multiple custom service accounts or pods using them in `default` often mean real applications are deployed there instead of in dedicated namespaces.

        6. Verify whether key applications are running in non-default namespaces

        If you know app labels (example: `app=frontend`), check where they run:

        ```bash theme={null}
        kubectl get pods --all-namespaces -l app=frontend -o wide
        ```

        Problem indication: If important applications only appear in the `default` namespace, that application team has not been segregated into a dedicated namespace.

        These commands only surface the current state. Deciding which resources should move to dedicated namespaces and how to redesign access controls requires human review of:

        * Which objects are system/cluster-critical vs. app workloads.
        * Which teams/owners should have separate namespaces.
        * How RBAC and network policies will map to the new namespace structure.
      </Accordion>

      <Accordion title="Automation">
        ```bash theme={null}
        #!/usr/bin/env bash
        # Report resources still using the "default" namespace
        # Run on: any machine with kubectl access and appropriate RBAC

        set -euo pipefail

        echo "=== Context ==="
        kubectl config current-context || true
        echo

        echo "=== Workloads in the 'default' namespace ==="
        echo
        echo "-- Pods (non-daemon, non-static) --"
        kubectl get pods -n default -o wide || true
        echo

        echo "-- Deployments --"
        kubectl get deploy -n default -o wide || true
        echo

        echo "-- StatefulSets --"
        kubectl get statefulset -n default -o wide || true
        echo

        echo "-- DaemonSets --"
        kubectl get daemonset -n default -o wide || true
        echo

        echo "-- Jobs --"
        kubectl get jobs -n default -o wide || true
        echo

        echo "-- CronJobs --"
        kubectl get cronjobs -n default -o wide || true
        echo

        echo "=== Services, Ingresses, and Endpoints in 'default' ==="
        echo
        echo "-- Services --"
        kubectl get svc -n default -o wide || true
        echo

        echo "-- Ingresses --"
        kubectl get ingress -n default -o wide || true
        echo

        echo "-- Endpoints --"
        kubectl get endpoints -n default -o wide || true
        echo

        echo "=== RBAC references to the 'default' namespace ==="
        echo
        echo "-- RoleBindings in 'default' --"
        kubectl get rolebinding -n default -o wide || true
        echo

        echo "-- ClusterRoles/ClusterRoleBindings mentioning 'default' in subjects --"
        kubectl get clusterrolebinding -o json \
          | jq -r '.items[]
            | select(.subjects != null)
            | select([.subjects[]?.namespace] | any(. == "default"))
            | .metadata.name' 2>/dev/null || true
        echo

        echo "=== Config and policy resources in 'default' ==="
        echo
        echo "-- ConfigMaps --"
        kubectl get configmap -n default -o wide || true
        echo

        echo "-- Secrets --"
        kubectl get secret -n default -o wide || true
        echo

        echo "-- NetworkPolicies --"
        kubectl get networkpolicy -n default -o wide || true
        echo

        echo "-- PodSecurityPolicies referencing 'default' (if PSP is enabled) --"
        kubectl get psp -o yaml 2>/dev/null \
          | grep -n "namespace: default" || true
        echo

        echo "=== Admission / Policy configurations that may treat 'default' specially ==="
        echo
        echo "-- ValidatingWebhookConfiguration mentioning 'default' --"
        kubectl get validatingwebhookconfiguration -o yaml 2>/dev/null \
          | grep -n "namespace: default" || true
        echo

        echo "-- MutatingWebhookConfiguration mentioning 'default' --"
        kubectl get mutatingwebhookconfiguration -o yaml 2>/dev/null \
          | grep -n "namespace: default" || true
        echo

        echo "=== Summary hint ==="
        echo "Any non-system workload, service, config, or RBAC object listed above in the 'default'"
        echo "namespace should be reviewed. In general, only temporary test resources or carefully"
        echo "justified exceptions should appear in 'default'."
        ```

        Explanation of problematic output:

        * Any long-lived or production workload (Deployments, StatefulSets, DaemonSets, Jobs/CronJobs) listed under `default` indicates a problem; these should be moved to dedicated namespaces.
        * Services, Ingresses, ConfigMaps, Secrets, and NetworkPolicies in `default` tied to those workloads are also problematic and should be migrated with the workloads.
        * RoleBindings in `default` and ClusterRoleBindings whose `subjects` reference `namespace: default` may be overly broad; review whether access should instead be scoped to specific application namespaces.
        * Webhook, PSP, or other policy configurations that special-case `namespace: default` should be reviewed to ensure they are not encouraging or relying on use of the default namespace.
      </Accordion>
    </AccordionGroup>
  </Tab>
</Tabs>