> ## 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 security boundaries between sets of resources. Create dedicated namespaces to segregate workloads and apply scoped RBAC controls.

### Risk Level

Low

### Address

Security

### Compliance Standards

* CIS EKS

### Triage and Remediation

<Tabs>
  <Tab title="Remediation">
    ### Remediation

    <AccordionGroup>
      <Accordion title="Manual Steps" defaultOpen="true">
        1. **Inventory current namespaces and their workloads**
           * Run on: any machine with kubectl access
           * Command:
             ```bash theme={null}
             kubectl get namespaces
             kubectl get all --all-namespaces
             ```
           * Review whether business-critical, shared, and system workloads are clearly separated (e.g., `kube-system`, `kube-public`, provider-managed namespaces vs. your own application namespaces).

        2. **Identify workloads running in default or shared namespaces**
           * Run on: any machine with kubectl access
           * Command:
             ```bash theme={null}
             kubectl get all -n default
             kubectl get all -n kube-system
             kubectl get all -n kube-public
             kubectl get all -n kube-node-lease
             ```
           * Determine which of these are your application workloads (not system or add-ons) and whether they should be isolated into dedicated namespaces (e.g., per team, environment, or application).

        3. **Design a namespace strategy and plan moves**
           * Decide target namespaces (e.g., `team-a-prod`, `team-a-dev`, `shared-tools`) and which workloads must be isolated for security, access control, or quota reasons.
           * For each workload in an inappropriate namespace, plan:
             * Target namespace name
             * Matching RBAC scope (ServiceAccounts, Roles, RoleBindings)
             * Any NetworkPolicies or ResourceQuotas/LimitRanges to apply.

        4. **Create or update namespaces and associated policies**
           * Run on: any machine with kubectl access
           * Command (example – adjust names and labels to your design):
             ```bash theme={null}
             kubectl create namespace team-a-prod
             kubectl label namespace team-a-prod env=prod team=team-a --overwrite
             ```
           * Optionally add baseline policies per namespace, for example:
             ```bash theme={null}
             # Example Role scoped to the namespace
             cat <<'EOF' | kubectl apply -f -
             apiVersion: rbac.authorization.k8s.io/v1
             kind: Role
             metadata:
               name: app-readonly
               namespace: team-a-prod
             rules:
             - apiGroups: [""]
               resources: ["pods","services","configmaps","secrets"]
               verbs: ["get","list","watch"]
             EOF
             ```

        5. **Migrate workloads into their dedicated namespaces**
           * Run on: any machine with kubectl access
           * Export and re-apply manifests into the new namespaces (update `metadata.namespace`):
             ```bash theme={null}
             # Example: export a deployment currently in default namespace
             kubectl get deploy my-app -n default -o yaml > my-app.yaml
             sed -i 's/namespace: default/namespace: team-a-prod/' my-app.yaml
             kubectl apply -f my-app.yaml
             kubectl delete deploy my-app -n default
             ```
           * Ensure related objects (Services, ConfigMaps, Secrets, ServiceAccounts, Roles/RoleBindings, NetworkPolicies) are also created in the target namespace and references are updated.

        6. **Verify namespace boundaries and workload placement**
           * Run on: any machine with kubectl access
           * Commands:
             ```bash theme={null}
             kubectl get namespaces --show-labels
             kubectl get all --all-namespaces
             ```
           * Confirm that:
             * Non-system workloads are no longer running in `default` or system namespaces unless explicitly intended.
             * Workloads are grouped into appropriate dedicated namespaces that align with your administrative and security boundaries.
      </Accordion>

      <Accordion title="Using kubectl">
        ```bash theme={null}
        # 1. List all namespaces and their age
        # Run on: any machine with kubectl access
        kubectl get namespaces -o wide
        ```

        **What to look for (possible issues):**

        * Only `default`, `kube-system`, `kube-public`, and `kube-node-lease` exist, but many workloads run in `default`.
        * Very old `default` namespace with many unrelated workloads suggests no logical separation.

        ***

        ```bash theme={null}
        # 2. See which namespaces workloads are running in (workloads only)
        kubectl get deploy,sts,ds,job,cronjob,svc,ingress --all-namespaces
        ```

        **What to look for:**

        * Multiple unrelated applications (e.g., payments, logging, demo, staging, prod) all in the same namespace (often `default`).
        * Shared namespace between system components and business apps.

        ***

        ```bash theme={null}
        # 3. List all pods with labels to infer logical groupings
        kubectl get pods --all-namespaces --show-labels
        ```

        **What to look for:**

        * Labels like `app=payments`, `env=prod`, `team=ml`, etc., all in one namespace instead of being grouped into separate namespaces by environment, team, or function.
        * No clear correlation between labels and namespace boundaries.

        ***

        ```bash theme={null}
        # 4. Inspect RBAC bindings and where they apply
        kubectl get rolebinding,clusterrolebinding --all-namespaces -o wide
        ```

        **What to look for:**

        * Overuse of `ClusterRoleBinding` granting broad roles (e.g., `cluster-admin`) instead of namespace-scoped `RoleBinding`.
        * Critical or sensitive workloads in namespaces that share wide RBAC bindings with unrelated workloads.

        ***

        ```bash theme={null}
        # 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
        ```

        **What to look for:**

        * A namespace mixing:
          * different environments (dev/test/prod),
          * different business domains (payments, analytics, logging),
          * different teams or tenants,
            all with similar RBAC permissions.
        * Lack of any dedicated namespaces for components that clearly should be isolated (e.g., security tools, logging, monitoring, prod workloads).

        ***

        ```bash theme={null}
        # 6. Identify workloads still running in the default namespace
        kubectl get all -n default
        ```

        **What to look for:**

        * Long-lived application workloads or critical services in `default` instead of a dedicated namespace (e.g., `payments-prod`, `team-a-dev`, `logging`, `monitoring`).

        ***

        ```bash theme={null}
        # 7. (Optional) Show namespace labels/annotations that may indicate intended boundaries
        kubectl get ns -o yaml
        ```

        **What to look for:**

        * Important logical groups (tenant, team, env, data-sensitivity) present only as labels but not used to define actual namespace boundaries (e.g., multiple teams or envs mixed in one namespace despite labels suggesting separation is desired).

        ***

        If these commands show that unrelated teams, environments, or sensitivity levels are mixed in the same namespaces, or that most workloads live in `default`, the cluster likely lacks appropriate administrative boundaries and requires a human-designed namespace model and migration plan.
      </Accordion>

      <Accordion title="Automation">
        ```bash theme={null}
        #!/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
        ```
      </Accordion>
    </AccordionGroup>
  </Tab>
</Tabs>