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 workloads are running in (workloads only)
kubectl get deploy,sts,ds,job,cronjob,svc,ingress --all-namespaces

# 3. List all pods with labels to infer logical groupings
kubectl get pods --all-namespaces --show-labels

# 4. Inspect RBAC bindings and where they apply
kubectl get rolebinding,clusterrolebinding --all-namespaces -o wide

# 5. For a specific namespace, inspect its RBAC in detail
NAMESPACE=default   # replace with namespace under review
kubectl get role,rolebinding -n "${NAMESPACE}" -o yaml
kubectl get pods,svc,deploy,sts,ds,job,cronjob,ingress -n "${NAMESPACE}" -o yaml

# 6. Identify workloads still running in the default namespace
kubectl get all -n default

# 7. (Optional) Show namespace labels/annotations that may indicate intended boundaries
kubectl get ns -o yaml

#!/usr/bin/env bash
# Assess namespace usage to review administrative boundaries
# Run on: any machine with kubectl access and cluster-wide read permissions

set -euo pipefail

echo "=== 1) List all namespaces with age and labels (for grouping/ownership) ==="
kubectl get ns --show-labels -o wide

echo
echo "=== 2) Workloads per namespace (Pods, Deployments, StatefulSets, DaemonSets, Jobs, CronJobs) ==="
for ns in $(kubectl get ns -o jsonpath='{range .items[*]}{.metadata.name}{"\n"}{end}'); do
  echo
  echo "----- Namespace: ${ns} -----"
  kubectl get pods,deploy,sts,ds,job,cronjob -n "${ns}" 2>/dev/null || echo "  (no core workloads or no permission)"
done

echo
echo "=== 3) ServiceAccounts and their usage per namespace ==="
for ns in $(kubectl get ns -o jsonpath='{range .items[*]}{.metadata.name}{"\n"}{end}'); do
  echo
  echo "----- Namespace: ${ns} -----"
  echo "- ServiceAccounts:"
  kubectl get sa -n "${ns}" -o wide 2>/dev/null || echo "  (no serviceaccounts or no permission)"
  echo
  echo "- Pods and their ServiceAccounts:"
  kubectl get pods -n "${ns}" -o custom-columns='NAMESPACE:.metadata.namespace,POD:.metadata.name,SA:.spec.serviceAccountName' 2>/dev/null \
    || echo "  (no pods or no permission)"
done

echo
echo "=== 4) Cluster-wide RBAC resources referencing namespaces ==="
echo
echo "- ClusterRoles (cluster-scoped permissions):"
kubectl get clusterrole
echo
echo "- ClusterRoleBindings (who has cluster-scoped permissions):"
kubectl get clusterrolebinding -o wide

echo
echo "=== 5) Namespaced RBAC per namespace ==="
for ns in $(kubectl get ns -o jsonpath='{range .items[*]}{.metadata.name}{"\n"}{end}'); do
  echo
  echo "----- Namespace: ${ns} -----"
  echo "- Roles:"
  kubectl get role -n "${ns}" -o wide 2>/dev/null || echo "  (no Roles or no permission)"
  echo
  echo "- RoleBindings:"
  kubectl get rolebinding -n "${ns}" -o wide 2>/dev/null || echo "  (no RoleBindings or no permission)"
done

echo
echo "=== 6) High-privilege bindings (cluster-admin or similar) by subject and namespace ==="
# Cluster-admin via ClusterRoleBinding
echo
echo "- ClusterRoleBindings that grant 'cluster-admin':"
kubectl get clusterrolebinding -o json \
  | jq -r '
      .items[]
      | select(.roleRef.kind=="ClusterRole" and .roleRef.name=="cluster-admin")
      | "Binding: \(.metadata.name)\n  Subjects:\n" +
        ( .subjects[]?
          | "    - kind: \(.kind), name: \(.name), namespace: \(.namespace // "-")"
        )
    ' || echo "jq not installed; skip detailed view (install jq to see more detail)"

# Detect RoleBindings that refer to high-privilege ClusterRoles (by name pattern)
echo
echo "- RoleBindings that reference ClusterRoles (potential cross-namespace high privilege):"
kubectl get rolebinding --all-namespaces -o json \
  | jq -r '
      .items[]
      | select(.roleRef.kind=="ClusterRole")
      | "Namespace: \(.metadata.namespace), RoleBinding: \(.metadata.name), ClusterRoleRef: \(.roleRef.name)"
    ' || echo "jq not installed; skip this check"

echo
echo "=== 7) Pods running in core / shared namespaces (kube-system, default, kube-public) ==="
for ns in default kube-system kube-public; do
  echo
  echo "----- Namespace: ${ns} -----"
  kubectl get pods -n "${ns}" -o wide 2>/dev/null || echo "  (namespace not found or no pods)"
done

echo
echo "=== 8) Summary hint (manual review required) ==="
cat <<'EOF'
Manual review guidance (what output indicates a potential problem):

1) From section 1:
   - Workloads concentrated heavily in 'default' or other shared/core namespaces
     instead of being grouped into dedicated application or team namespaces.
   - Lack of meaningful labels (e.g., missing team/app/env/owner labels) that would
     indicate clear administrative ownership of namespaces.

2) From section 2:
   - Multiple unrelated applications or teams sharing the same namespace.
   - System components and tenant workloads mixed in the same namespace.

3) From section 3:
   - Many pods in a namespace sharing a single broad ServiceAccount instead of
     more granular ServiceAccounts per application or function.

4) From sections 4 and 6:
   - Frequent or broad use of 'cluster-admin' via ClusterRoleBindings (especially
     bound to users/groups that should be limited to specific namespaces).
   - RoleBindings that reference ClusterRoles across namespaces, implying
     potentially unnecessary cluster-wide privileges for namespace-scoped users.

5) From section 5:
   - Namespaces with workloads but no namespace-scoped Roles/RoleBindings,
     relying solely on cluster-scoped RBAC (weakens namespace boundaries).

6) From section 7:
   - Tenant or application workloads running in 'kube-system', 'kube-public',
     or 'default' instead of dedicated namespaces.

Use these findings to decide where to:
- Introduce new namespaces to separate teams, environments, or applications.
- Tighten RBAC so users and ServiceAccounts have access only to their namespaces.
EOF