Create Administrative Boundaries Between Resources Using Namespaces

Manual Steps

Inventory current namespaces and their workloads
Run on any machine with kubectl access:
kubectl get namespaces kubectl get all --all-namespaces
Review whether business-critical applications, shared infrastructure, and testing workloads are clearly separated into different namespaces instead of using default.
Identify workloads in the default namespace or other catch‑all namespaces
kubectl get all -n default
If you have any custom workloads in default (or a single large shared namespace), decide how they should be grouped (e.g., by application, environment such as dev/stage/prod, or team/tenant).
Design the namespace model and create required namespaces
Decide and document which namespaces you need (for example: app1-prod, app1-dev, shared-infra, team-a, team-b).
Create them:
kubectl create namespace app1-prod kubectl create namespace app1-dev kubectl create namespace shared-infra # add or adjust names as per your design
Plan and apply resource re-homing into the new namespaces
For each workload currently in default (or another overly broad namespace), export and adjust its manifests:
# example for a deployment in default kubectl get deployment my-deployment -n default -o yaml > my-deployment.yaml
Edit my-deployment.yaml to set:
metadata: namespace: app1-prod # or your chosen namespace
Then re-apply in the target namespace and delete the old resource if needed:
kubectl apply -f my-deployment.yaml kubectl delete deployment my-deployment -n default
Repeat for Services, ConfigMaps, Secrets, Jobs, etc., as appropriate, verifying dependencies (e.g., Service selectors, config references).
Align access control and policies with the new namespaces
For each new namespace, ensure RBAC and policies match the intended boundary:
kubectl get role,rolebinding,networkpolicy,resourcequota,limitrange -n app1-prod
Create or adjust Role, RoleBinding, NetworkPolicy, ResourceQuota, and LimitRange objects so that teams/apps can only access their own namespaces and appropriate resource limits are enforced.
Verify namespace-based separation is in effect
Confirm that application workloads now reside in their intended namespaces and that default contains no (or only minimal/expected) workloads:
kubectl get all --all-namespaces kubectl get all -n default
Review that resources are grouped according to your designed boundaries and that cross-namespace access (via RBAC and policies) matches your administrative intent.

Using kubectl

# 1) List all namespaces and age
# Run on: any machine with kubectl access
kubectl get namespaces -o wide

Review guidance:

Potential problem if you see only the default/system namespaces (default, kube-system, kube-public, kube-node-lease, any cloud-provider system namespaces) and no application- or team-specific namespaces.
Also a problem if there is a single custom namespace that appears to host all workloads, suggesting no meaningful separation.

# 2) List all pods in ALL namespaces to see how workloads are distributed
kubectl get pods --all-namespaces -o wide

Review guidance:

Potential problem if most or all non-system workloads are in the default namespace.
Potential problem if unrelated applications (different teams, environments, or sensitivity levels) all run in the same namespace.

# 3) Inspect which namespaces individual workloads are using by type
kubectl get deploy,sts,ds,job,cronjob --all-namespaces

Review guidance:

Look for patterns like:
- All Deployments in default.
- Shared namespaces mixing dev/test/prod or internal/external workloads.
This suggests missing administrative boundaries.

# 4) Check RBAC bindings per namespace (to see if boundaries are being used)
kubectl get rolebindings,roles -A
kubectl get clusterrolebindings,clusterroles

Review guidance:

If access control is mostly via ClusterRoleBinding to wide roles (e.g., cluster-admin) and there are few or no namespace-scoped Role/RoleBinding objects, namespaces are likely not being used as effective boundaries.
If a single namespace’s roles grant broad access to many unrelated resources, it may indicate poor separation.

# 5) Optionally, count non-system workloads by namespace
kubectl get pods --all-namespaces \
  | grep -vE 'kube-system|kube-public|kube-node-lease|NAME' \
  | awk '{print $1}' \
  | sort | uniq -c | sort -nr

Review guidance:

If the vast majority of non-system pods are in the default namespace (or a single shared namespace), administrative boundaries are likely inadequate.

# 6) Verify after any namespace restructuring
kubectl get namespaces -o wide
kubectl get deploy,sts,ds,job,cronjob --all-namespaces
kubectl get pods --all-namespaces -o wide

Verification guidance:

You should see multiple, clearly named namespaces (e.g., per environment, team, or application).
Non-system workloads should be spread across those namespaces in a way that matches your intended administrative and access-control boundaries.

Automation

#!/usr/bin/env bash
# Report namespace usage to help review administrative boundaries
# Runs on: any machine with kubectl access and current-context pointing to the target cluster

set -euo pipefail

echo "=== 1) Namespaces overview ==="
kubectl get namespaces -o custom-columns=NAME:.metadata.name,STATUS:.status.phase,AGE:.metadata.creationTimestamp

echo
echo "=== 2) Workloads per namespace (Deployments, StatefulSets, DaemonSets, Jobs, CronJobs) ==="
kubectl get deploy,sts,ds,job,cronjob -A \
  -o custom-columns=KIND:.kind,NAMESPACE:.metadata.namespace,NAME:.metadata.name \
  | sort -k2,2 -k1,1 -k3,3

echo
echo "=== 3) Services per namespace ==="
kubectl get svc -A \
  -o custom-columns=NAMESPACE:.metadata.namespace,NAME:.metadata.name,TYPE:.spec.type,CLUSTER_IP:.spec.clusterIP \
  | sort -k1,1 -k2,2

echo
echo "=== 4) Pods running in the 'default' namespace (focus area) ==="
kubectl get pods -n default \
  -o custom-columns=NAME:.metadata.name,OWNER_KIND:.metadata.ownerReferences[*].kind,OWNER_NAME:.metadata.ownerReferences[*].name \
  --ignore-not-found

echo
echo "=== 5) ClusterRoles / RoleBindings to detect broad access across namespaces ==="
echo "--- ClusterRoles (cluster-wide permissions) ---"
kubectl get clusterrole -o custom-columns=NAME:.metadata.name,AGE:.metadata.creationTimestamp \
  | sort

echo
echo "--- ClusterRoleBindings and their subjects (who can access across namespaces) ---"
kubectl get clusterrolebinding -o yaml | awk '
  $1=="kind:"{kind=$2}
  $1=="name:"&&kind=="ClusterRoleBinding"{crb=$2}
  /roleRef:/ {inRoleRef=1; next}
  inRoleRef && $1=="name:"{role=$2; inRoleRef=0}
  /subjects:/ {inSubjects=1; next}
  inSubjects && $1=="-"{
    getline; gsub("kind:",""); sub(/^[ \t]+/,""); sKind=$0
    getline; gsub("name:",""); sub(/^[ \t]+/,""); sName=$0
    getline; gsub("namespace:",""); sub(/^[ \t]+/,""); sNs=$0
    if(sNs=="") sNs="-"
    printf "%-40s %-30s %-12s %-30s %-20s\n", crb, role, sKind, sName, sNs
  }
' | sort

echo
echo "=== 6) Roles / RoleBindings per namespace (for detailed review) ==="
for ns in $(kubectl get ns -o jsonpath='{.items[*].metadata.name}'); do
  echo "--- Namespace: ${ns} ---"
  echo "Roles:"
  kubectl get role -n "${ns}" \
    -o custom-columns=NAME:.metadata.name,AGE:.metadata.creationTimestamp \
    --ignore-not-found \
    | sed 's/^/  /'
  echo "RoleBindings:"
  kubectl get rolebinding -n "${ns}" \
    -o custom-columns=NAME:.metadata.name,ROLE:.roleRef.name \
    --ignore-not-found \
    | sed 's/^/  /'
  echo
done

echo "=== 7) Summary: workloads per namespace (counts) ==="
kubectl get deploy,sts,ds,job,cronjob -A -o custom-columns=NAMESPACE:.metadata.namespace,NAME:.metadata.name \
  | awk 'NR>1{count[$1]++} END{printf "%-30s %s\n","NAMESPACE","WORKLOAD_COUNT"; for (ns in count) printf "%-30s %d\n", ns, count[ns] | "sort"}'

Explanation of what indicates a potential problem:

Many application Pods/Deployments/Services appear in the default namespace (section 4 and summary section 7), especially if used by multiple teams or environments.
Critical, unrelated applications share the same namespace (check section 2 and 3 for “crowded” namespaces mixing different systems or teams).
Broad ClusterRoles and ClusterRoleBindings in section 5 show many subjects (users, groups, service accounts) bound to powerful roles, effectively bypassing namespace isolation.
Namespaces with workloads but few or no Roles/RoleBindings (section 6) may lack fine-grained, namespace-scoped RBAC.

Use this report to decide where to:

Create additional namespaces to separate teams, environments (dev/test/prod), or applications.
Move workloads out of default into specific namespaces.
Tighten RBAC so access is appropriately constrained per namespace.

OCI Misconfigurations

Create Administrative Boundaries Between Resources Using Namespaces

More Info:

Risk Level

Address

Compliance Standards

Triage and Remediation

Remediation

​More Info:

​Risk Level

​Address

​Compliance Standards

​Triage and Remediation

​Remediation

More Info:

Risk Level

Address

Compliance Standards

Triage and Remediation

Remediation