> ## 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. # Create Administrative Boundaries Between Resources Using Namespaces ### More Info: Namespaces provide administrative and access-control boundaries between groups of resources. Create namespaces to segregate resources and place new resources in a specific namespace. ### Risk Level Low ### Address Security ### Compliance Standards * CIS OKE ### Triage and Remediation ### Remediation 1. **Inventory current namespaces and their workloads**\ Run on any machine with kubectl access: ```bash theme={null} 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`. 2. **Identify workloads in the `default` namespace or other catch‑all namespaces** ```bash theme={null} 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). 3. **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: ```bash theme={null} kubectl create namespace app1-prod kubectl create namespace app1-dev kubectl create namespace shared-infra # add or adjust names as per your design ``` 4. **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: ```bash theme={null} # example for a deployment in default kubectl get deployment my-deployment -n default -o yaml > my-deployment.yaml ``` Edit `my-deployment.yaml` to set: ```yaml theme={null} metadata: namespace: app1-prod # or your chosen namespace ``` Then re-apply in the target namespace and delete the old resource if needed: ```bash theme={null} 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). 5. **Align access control and policies with the new namespaces**\ For each new namespace, ensure RBAC and policies match the intended boundary: ```bash theme={null} 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. 6. **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: ```bash theme={null} 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. ```bash theme={null} # 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. ```bash theme={null} # 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. ```bash theme={null} # 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. ```bash theme={null} # 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. ```bash theme={null} # 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. ```bash theme={null} # 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. ```bash theme={null} #!/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.