The Default Namespace Should Not Be Used

Manual Steps

List all workloads and core resources in the default namespace
- Run on: any machine with kubectl access
kubectl get all,cm,secret,sa,role,rolebinding,networkpolicy -n default kubectl get ingress -n default kubectl get pvc -n default
Review whether each object is intentionally in default or just there by habit/convenience.
Identify ownership and required segregation for each object
- Run on: any machine with kubectl access
kubectl get deploy,sts,ds,job,cronjob -n default -o wide kubectl get svc -n default -o wide kubectl get sa,role,rolebinding -n default -o yaml
For each application or component, decide:
- Which team/tenant owns it.
- What security or lifecycle boundaries it needs.
- What namespace(s) should exist instead (e.g., team-a-prod, shared-infra, monitoring).
Create or confirm purpose-specific namespaces
- Run on: any machine with kubectl access
  For each logical grouping you identified:
kubectl create namespace team-a-prod kubectl create namespace shared-infra
(Adjust names as decided; skip if already present: kubectl get ns to check.)
Optionally add labels/annotations to express purpose/ownership:
kubectl label namespace team-a-prod owner=team-a env=prod --overwrite
Plan and migrate resources out of default to their target namespaces
- Run on: any machine with kubectl access
  For each object to move:
1. Export its manifest:
  kubectl get deployment my-app -n default -o yaml > my-app.yaml
2. Edit the file:
  - Change metadata.namespace: default to the target namespace.
  - Update references (serviceAccountName, ConfigMap/Secret names, RoleBindings, NetworkPolicies) if they change.
3. Apply to the new namespace and delete from default:
  kubectl apply -f my-app.yaml kubectl delete deployment my-app -n default
Repeat this pattern for Services, ConfigMaps, Secrets, ServiceAccounts, Roles/RoleBindings, NetworkPolicies, Jobs/CronJobs, PVCs (being careful with data and StorageClass constraints).
Harden RBAC and defaults to discourage future use of default
- Run on: any machine with kubectl access
  Consider:
- Removing broad bindings in default:
  kubectl get rolebinding,clusterrolebinding -A | grep default kubectl delete rolebinding <name> -n default
- Creating least-privilege RoleBindings only in intended namespaces and ensuring users’ kubeconfigs specify a non-default namespace:
  kubectl config set-context $(kubectl config current-context) --namespace=team-a-prod
Verify that default is no longer used for application resources
- Run on: any machine with kubectl access
kubectl get all,cm,secret,sa,role,rolebinding,networkpolicy,ingress,pvc -n default
Confirm that:
- Only objects you explicitly want there remain (often just system bootstrap artifacts, if any).
- All application, team, or environment-specific resources have been moved to purpose-specific namespaces.

Using kubectl

Run these commands from any machine with kubectl access.

1. List all namespaces and spot obvious mis-use of `default`

kubectl get ns

What to look for (potential problems):

Only default, kube-system, and other system namespaces exist, and no clearly purpose-specific namespaces for apps or teams.
Application names suggest they should have their own namespaces, but do not (e.g., you see payments, frontend as Deployments in default later).

2. See what is currently running in the `default` namespace

kubectl get all -n default

If you also use other workload types:

kubectl get deploy,sts,ds,job,cronjob,svc,ingress,cm,secret -n default

What to look for (potential problems):

Business applications (e.g., orders-api, payments-db, frontend) running in default.
Shared infrastructure components (e.g., logging, monitoring, CI/CD agents) running in default.
Any long-lived workloads or services that clearly belong to a specific team, environment (dev/test/prod), or function, but are not in a dedicated namespace.

Using default for:

Only temporary/manual testing objects, clearly named as such and cleaned up regularly, is usually acceptable.
Anything production-like is a concern.

3. Check RBAC bindings that reference the `default` namespace

kubectl get rolebindings,roles -n default

What to look for (potential problems):

Broad roles (e.g., with * verbs or many resources) attached in default, especially if:
- default contains many or critical workloads.
- ServiceAccounts in default are used by multiple apps/teams.

This indicates access control is being applied to a “catch-all” namespace instead of segregated namespaces.

4. Check what is using the `default` ServiceAccount

kubectl get pods -n default -o custom-columns='POD:.metadata.name,SA:.spec.serviceAccountName'

What to look for (potential problems):

Many or critical pods using the implicit default ServiceAccount (<none> or default in the output), especially if:
- Those pods belong to distinct applications that should have isolated privileges.
- There are no app-specific ServiceAccounts/roles/namespaces.

This suggests both namespace and identity segregation are not being used.

5. Review cluster-wide workloads that omit a namespace (using `default` implicitly)

To spot resources that may be created without specifying -n or metadata.namespace:

kubectl get deploy,sts,ds,job,cronjob,svc,ingress,cm,secret --all-namespaces | grep ' default '

What to look for (potential problems):

Any production or shared system component appearing in default.
Patterns showing that most application resources land in default instead of in dedicated namespaces.

Use these observations to decide:

Which applications or components currently in default should be moved into dedicated namespaces.
What namespace structure (per app, per team, per environment) best supports your access control and segregation requirements.

Automation

#!/usr/bin/env bash
#
# Report all workload and access-control resources that are using the "default" namespace.
# Run on: any machine with kubectl access and current-context set to the target cluster.
# Requirements: kubectl, jq

set -euo pipefail

# Helper: safe kubectl get with nice headers
kget() {
  local ns="$1"; shift
  local kind="$1"; shift
  echo
  echo "=== ${kind} in namespace '${ns}' ==="
  kubectl get "${kind}" -n "${ns}" -o wide --ignore-not-found
}

echo "Cluster context: $(kubectl config current-context)"
echo "Reporting use of the 'default' namespace..."
echo

# 1. Basic inventory of the 'default' namespace
echo "=== Namespaces summary (showing if 'default' exists) ==="
kubectl get ns default || true
echo

echo "=== Resource counts by namespace (workloads, services, secrets, configmaps) ==="
kubectl get deploy,ds,sts,cronjob,job,po,svc,cm,secret --all-namespaces \
  -o json \
  | jq -r '
    .items[]
    | .metadata.namespace as $ns
    | $ns // "default"
  ' 2>/dev/null \
  | sort \
  | uniq -c \
  | sort -nr
echo

# 2. Detailed listing of all common resource types in 'default'
kget default deploy
kget default daemonset
kget default statefulset
kget default cronjob
kget default job
kget default pod
kget default svc
kget default ingress
kget default configmap
kget default secret
kget default pvc
kget default role
kget default rolebinding
kget default serviceaccount
kget default networkpolicy
kget default hpa
kget default pdb

# 3. ClusterRoles / ClusterRoleBindings that reference the default namespace explicitly
echo
echo "=== ClusterRoleBindings referencing ServiceAccounts in 'default' namespace ==="
kubectl get clusterrolebinding -o json \
  | jq -r '
      .items[]
      | {
          name: .metadata.name,
          subjects: (.subjects // [])
        }
      | select([.subjects[]? | select(.kind=="ServiceAccount" and .namespace=="default")] | length > 0)
      | .name
    ' 2>/dev/null \
  | sed 's/^/clusterrolebinding\//'
echo

# 4. (Optional) Detect namespaces with no resources at all (for comparison)
echo "=== Namespaces with zero Deployments, StatefulSets, DaemonSets, or Services (for context) ==="
all_ns=$(kubectl get ns -o jsonpath='{.items[*].metadata.name}')
for ns in $all_ns; do
  cnt=$(kubectl get deploy,ds,sts,svc -n "$ns" --ignore-not-found -o json \
    | jq '.items | length')
  if [ "$cnt" -eq 0 ]; then
    echo "$ns"
  fi
done

echo
echo "Report complete."

cat <<'EOF'

HOW TO INTERPRET THIS OUTPUT
----------------------------
This benchmark expects the "default" namespace not to be used for application or
tenant workloads. It is typically acceptable only for:
- Minimal bootstrap/system objects (if absolutely required by your platform/tooling).
- Temporary/testing resources in non-production clusters (by explicit policy).

Indicators of a problem:
- Any application Deployments/DaemonSets/StatefulSets/Jobs/CronJobs listed under:
    === * in namespace 'default' ===
- Any user-facing Services or Ingresses in the 'default' namespace.
- ConfigMaps/Secrets in 'default' that belong to real applications (e.g. database creds).
- ServiceAccounts, Roles, or RoleBindings in 'default' that are used by production apps.
- ClusterRoleBindings that grant powerful roles to ServiceAccounts in the 'default' namespace.

Use this report to:
1. Identify which teams/owners have workloads in 'default'.
2. Decide whether each resource must be migrated into a purpose-specific namespace.
3. Define a policy (e.g., admission control) to prevent future creation of resources
   in the 'default' namespace, once migration is complete.

Note: This script does NOT change the cluster; it only reports current usage so
you can make manual, policy-driven decisions consistent with the benchmark.
EOF

Kubernetes

Kubernetes Misconfigurations

The Default Namespace Should Not Be Used

More Info:

Risk Level

Address

Compliance Standards

Triage and Remediation

Remediation

Using kubectl

1. List all namespaces and spot obvious mis-use of `default`

2. See what is currently running in the `default` namespace

3. Check RBAC bindings that reference the `default` namespace

4. Check what is using the `default` ServiceAccount

5. Review cluster-wide workloads that omit a namespace (using `default` implicitly)

​More Info:

​Risk Level

​Address

​Compliance Standards

​Triage and Remediation

​Remediation

​Using kubectl

​1. List all namespaces and spot obvious mis-use of default

​2. See what is currently running in the default namespace

​3. Check RBAC bindings that reference the default namespace

​4. Check what is using the default ServiceAccount

​5. Review cluster-wide workloads that omit a namespace (using default implicitly)

More Info:

Risk Level

Address

Compliance Standards

Triage and Remediation

Remediation

Using kubectl

1. List all namespaces and spot obvious mis-use of `default`

2. See what is currently running in the `default` namespace

3. Check RBAC bindings that reference the `default` namespace

4. Check what is using the `default` ServiceAccount

5. Review cluster-wide workloads that omit a namespace (using `default` implicitly)