Create Administrative Boundaries Between Resources Using Namespaces

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

# 2) See which namespaces your Pods and Services actually use
kubectl get pods,svc --all-namespaces

# 3) Group workloads by namespace and label to understand boundaries
kubectl get pods --all-namespaces -o jsonpath='{range .items[*]}{.metadata.namespace}{"\t"}{.metadata.name}{"\t"}{.metadata.labels}{"\n"}{end}' \
  | sort

# 4) Check access controls per namespace (role bindings)
kubectl get rolebindings,roles --all-namespaces

# 5) Inspect a specific namespace’s contents in more detail
NAMESPACE=default  # change to the namespace you want to review

kubectl get all -n "$NAMESPACE" -o wide
kubectl get configmap,secret,ingress,networkpolicy -n "$NAMESPACE"

# 6) Review cluster-scoped bindings that might reduce the value of namespaces
kubectl get clusterrolebindings

# 7) Optional: summarize objects per namespace (for a rough boundary picture)
kubectl get ns -o jsonpath='{range .items[*]}{.metadata.name}{"\n"}{end}' \
  | while read ns; do
      echo "=== Namespace: $ns ==="
      kubectl get all -n "$ns" --no-headers 2>/dev/null | wc -l | awk '{print "Object count:", $1}'
    done

#!/usr/bin/env bash
# Report namespace usage and obvious multi-tenant risks
# Run on: any machine with kubectl access and current-context pointing to the target cluster

set -euo pipefail

echo "== Cluster-wide namespace summary =="
kubectl get ns --show-labels

echo
echo "== Namespaces with potentially sensitive or shared workloads (by common labels) =="
kubectl get pods -A -L 'app,app.kubernetes.io/name,app.kubernetes.io/part-of,tier,component' \
  -o custom-columns='NAMESPACE:.metadata.namespace,NAME:.metadata.name,APP:.metadata.labels.app,AKS_NAME:.metadata.labels.app\.kubernetes\.io/name,PART_OF:.metadata.labels.app\.kubernetes\.io/part-of,TIER:.metadata.labels.tier,COMPONENT:.metadata.labels.component' |
  awk 'NR==1 || $1!="NAMESPACE" {print}'

echo
echo "== Workloads running in the default namespace (red flag in most clusters) =="
kubectl get all -n default

echo
echo "== ClusterRoles & ClusterRoleBindings referencing subjects in shared namespaces =="
# This helps spot shared-admin patterns where multiple teams share a namespace
kubectl get clusterrole,clusterrolebinding -o yaml | awk '
  $1=="kind:"{k=$2}
  $1=="metadata:"{inm=1; next}
  inm && $1=="name:"{n=$2; gsub(/"/,"",n); inm=0}
  $1=="subjects:"{ins=1; next}
  ins && $1=="-"{ns=""; kind=""; name=""}
  ins && $1=="kind:"{kind=$2}
  ins && $1=="name:"{name=$2}
  ins && $1=="namespace:"{ns=$2}
  ins && $1=="-"{}
  ins && $1=="roleRef:"{ins=0}
  ins && ns!=""{
    gsub(/"/,"",ns); gsub(/"/,"",kind); gsub(/"/,"",name)
    print k"\t"n"\t"kind"\t"name"\t"ns
  }' | sort -u | column -t || true

echo
echo "== List of workloads per namespace (helps see shared vs isolated usage) =="
kubectl get deploy,sts,ds,job,cronjob -A -o custom-columns='KIND:.kind,NAMESPACE:.metadata.namespace,NAME:.metadata.name' | sort

echo
echo "== ServiceAccounts used by pods per namespace (for privilege / tenancy review) =="
kubectl get pods -A -o custom-columns='NAMESPACE:.metadata.namespace,POD:.metadata.name,SA:.spec.serviceAccountName' | sort

echo
echo "== NetworkPolicies per namespace (namespaces without any are more exposed) =="
kubectl get networkpolicy -A || echo "No NetworkPolicies found in cluster"

echo
echo "== Namespaces without any workloads (candidates for cleanup or future isolation) =="
all_ns=$(kubectl get ns -o jsonpath='{range .items[*]}{.metadata.name}{"\n"}{end}')
used_ns=$(kubectl get pods,deploy,sts,ds,job,cronjob -A -o jsonpath='{range .items[*]}{.metadata.namespace}{"\n"}{end}' | sort -u)
echo "${all_ns}" | sort -u | grep -v -F -x -f <(echo "${used_ns}" | sort -u) || true

echo
echo "== Guidance: How to interpret this output =="
cat <<'EOF'
Potential problems to look for manually:

1) Workloads in "default" namespace:
   - Any application pods, deployments, services, or jobs in the "default" namespace usually
     indicate missing administrative boundaries. Each logical app/team/tenant should normally
     have its own namespace.

2) Many unrelated apps in the same namespace:
   - In the workloads-per-namespace listing, if a namespace contains many unrelated apps
     (different teams, tenants, or environments like dev/test/prod together), that namespace
     likely lacks clear administrative separation.

3) Shared namespaces for different privilege levels:
   - In the ServiceAccounts-per-namespace section, if highly privileged SAs and unprivileged
     SAs are used in the same namespace, consider splitting them into separate namespaces with
     different RBAC and NetworkPolicies.

4) ClusterRoleBindings referencing many subjects in one namespace:
   - If the ClusterRole/ClusterRoleBinding section shows many human or app identities from
     one shared namespace getting broad cluster-wide privileges, that is an indicator that
     per-team or per-application namespaces are not being used as an administrative boundary.

5) Namespaces without NetworkPolicies:
   - Namespaces holding sensitive or multi-tenant workloads but lacking NetworkPolicies
     have weaker isolation. This is not strictly an RBAC boundary but is part of effective
     namespace-based isolation.

6) Unused or empty namespaces:
   - Namespaces with no workloads may be legacy or unused; decide whether to remove them or
     repurpose them explicitly so that namespace usage remains intentional and auditable.

This script only reports the current state. You must decide, per environment and business
requirements, where new namespaces are needed to separate teams, tenants, environments, or
privilege levels, and then refactor workloads and RBAC accordingly.
EOF