> ## 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.

# Minimize User Access Control To Container Engine For Kubernetes

### More Info:

Restrict assignment of powerful Kubernetes RBAC roles such as cluster-admin, which confers super-user privileges across all namespaces. Grant privileged roles only to users who genuinely require them.

### Risk Level

Medium

### Address

Security

### Compliance Standards

* CIS OKE

### Triage and Remediation

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

    <AccordionGroup>
      <Accordion title="Manual Steps" defaultOpen="true">
        1. **List all subjects bound to `cluster-admin` and other powerful roles**
           * Run on: any machine with `kubectl` access to the cluster
           * Command:
             ```bash theme={null}
             kubectl get clusterrolebinding -o wide
             kubectl get clusterrolebinding -o jsonpath='{range .items[?(@.roleRef.name=="cluster-admin")]}{.metadata.name}{"\t"}{.roleRef.name}{"\t"}{range .subjects[*]}{.kind}:{.name}{" "}{end}{"\n"}{end}'
             ```
           * Also identify other highly privileged bindings (if you use them by convention):
             ```bash theme={null}
             kubectl get clusterrolebinding -o json | jq -r '
               .items[]
               | select(.roleRef.name|test("admin|owner|cluster-admin"))
               | .metadata.name as $b
               | .roleRef.name as $r
               | "BINDING=\($b) ROLE=\($r) SUBJECTS=",
                 ( .subjects[]? | "  \(.kind):\(.name)" )
             '
             ```

        2. **Correlate Kubernetes subjects with OCI identities and roles**
           * In OCI Console, for each `User`, `Group`, or `ServiceAccount` from step 1:
             * Locate the corresponding OCI User/Group/Dynamic Group.
             * Review IAM policies granting them access to the cluster (e.g., `OKE` access policies, `manage cluster-family`, `manage cluster-node-pools`, etc.).
           * Using OCI CLI (run on any machine with OCI CLI configured) to list policies for a compartment:
             ```bash theme={null}
             oci iam policy list --compartment-id <OCID_of_compartment> --all
             ```

        3. **Decide who truly requires cluster-wide super-user privileges**
           * For each subject bound to `cluster-admin` or an equivalent highly privileged role, answer:
             * Is this a break-glass / platform admin account used only for cluster operations?
             * Is this an application/team account that could be scoped to specific namespaces or to less-privileged roles?
             * Is this an OCI tenancy administrator (who already has sufficient privileges without `cluster-admin`)?
           * Flag any subject that is:
             * Non-operational (e.g., developer, CI/CD, app service account) and
             * Not strictly required to manage the whole cluster.

        4. **Replace unnecessary `cluster-admin` bindings with narrower roles**
           * Design or select existing least-privilege `ClusterRole`/`Role` (via your IaC/cluster platform templates) that matches the actual operational need (e.g., namespace-scoped admin, read-only, or limited maintenance role).
           * Update your **cloud/IaC definitions** (Terraform/Resource Manager/other) so that:
             * Only a minimal set of platform operators retain `cluster-admin`.
             * Other users/groups/service accounts are granted scoped roles instead.
           * Apply the IaC changes through your standard deployment pipeline so that RBAC is reconciled from code rather than ad hoc changes.

        5. **Remove or tighten existing over-privileged bindings**
           * Once replacement access is defined in cloud/IaC and deployed, remove or edit the excessive bindings (run on any machine with `kubectl` access):
             ```bash theme={null}
             # Example: delete a specific clusterrolebinding granting cluster-admin
             kubectl delete clusterrolebinding <binding-name>
             ```
           * For bindings that must remain, ensure their subjects are restricted to:
             * A very small, auditable set of admin accounts.
             * No generic/shared or application identities.

        6. **Verify the final state and document the justification**
           * Re-run evidence commands (run on any machine with `kubectl` access):
             ```bash theme={null}
             kubectl get clusterrolebinding -o wide
             kubectl get clusterrolebinding -o jsonpath='{range .items[?(@.roleRef.name=="cluster-admin")]}{.metadata.name}{"\t"}{.roleRef.name}{"\t"}{range .subjects[*]}{.kind}:{.name}{" "}{end}{"\n"}{end}'
             ```
           * Confirm:
             * Only explicitly justified admin identities retain `cluster-admin`.
             * All other users/groups/service accounts are mapped (via OCI IAM + RBAC) to least-privilege roles.
           * Record in your security documentation which identities have `cluster-admin`, why they need it, and who approved it.
      </Accordion>

      <Accordion title="Using kubectl">
        kubectl cannot fix this finding because the over-privileged access is granted through Oracle Cloud Infrastructure IAM / Container Engine for Kubernetes (managed control plane configuration), not via in-cluster objects. Use the cloud console, OCI CLI, or IaC to review and adjust which identities are mapped to cluster-admin, following the guidance in the Manual Steps section.
      </Accordion>

      <Accordion title="Automation">
        ```bash theme={null}
        #!/usr/bin/env bash
        # Purpose: Report powerful RBAC usage (cluster-admin and similar) for review.
        # Run on: any machine with kubectl access and correct kubeconfig context.

        set -euo pipefail

        echo "=== Context ==="
        kubectl config current-context
        echo

        echo "=== ClusterRoleBindings to cluster-admin (direct) ==="
        kubectl get clusterrolebindings -o jsonpath='{range .items[?(@.roleRef.kind=="ClusterRole" && @.roleRef.name=="cluster-admin")]}{.metadata.name}{"|"}{.roleRef.name}{"|"}{range .subjects[*]}{.kind}:{.apiGroup}:{.name},{end}{"\n"}{end}' 2>/dev/null \
          | column -s"|" -t || echo "none found"
        echo
        cat <<'EOF'
        Interpretation:
        - Any subject listed here (User, Group, ServiceAccount) has cluster-admin via ClusterRoleBinding.
        - Problems to review:
          * Human users or broad groups (e.g. 'Administrators', 'ocid1.group.oc1..*') bound to cluster-admin.
          * Service accounts not clearly tied to cluster operations.
        EOF
        echo

        echo "=== RoleBindings to cluster-admin in all namespaces (indirect) ==="
        for ns in $(kubectl get ns -o jsonpath='{range .items[*]}{.metadata.name}{"\n"}{end}'); do
          kubectl get rolebindings -n "$ns" -o jsonpath="{range .items[?(@.roleRef.kind=='ClusterRole' && @.roleRef.name=='cluster-admin')]}${ns}|{.metadata.name}|{.roleRef.name}|{range .subjects[*]}{.kind}:{.apiGroup}:{.name},{end}{\"\n\"}{end}" 2>/dev/null
        done | column -s"|" -t || true
        echo
        cat <<'EOF'
        Interpretation:
        - Any subject listed here gets full cluster-admin via a namespaced RoleBinding.
        - Problems to review:
          * Use of cluster-admin in application namespaces.
          * Human users/groups or generic service accounts bound this way.
        EOF
        echo

        echo "=== ClusterRoleBindings to other highly-privileged ClusterRoles ==="
        # Heuristic: clusterroles with verbs including '*' or 'impersonate' or full on 'roles/clusterroles'
        kubectl get clusterroles -o json | jq -r '
          .items[]
          | select(
              any(.rules[]?; 
                  (.verbs[]? == "*" )
                  or (.verbs[]? == "impersonate")
                  or (.resources[]? == "clusterroles" or .resources[]? == "roles")
                )
            )
          | .metadata.name' | sort -u > /tmp/high_priv_roles.txt

        if [[ -s /tmp/high_priv_roles.txt ]]; then
          echo "Detected potentially high-privilege ClusterRoles:"
          cat /tmp/high_priv_roles.txt
          echo

          echo "ClusterRoleBindings using these ClusterRoles:"
          while read -r cr; do
            kubectl get clusterrolebindings -o jsonpath="{range .items[?(@.roleRef.kind=='ClusterRole' && @.roleRef.name=='$cr')]}$cr|{.metadata.name}|{range .subjects[*]}{.kind}:{.apiGroup}:{.name},{end}{\"\n\"}{end}" 2>/dev/null
          done < /tmp/high_priv_roles.txt | column -s"|" -t || true
        else
          echo "No additional high-privilege ClusterRoles found by heuristic."
        fi
        echo
        cat <<'EOF'
        Interpretation:
        - These roles *may* be equivalent to, or close to, cluster-admin.
        - Problems to review:
          * Custom ClusterRoles with wildcard verbs '*' on core resources, bound to human users/groups.
          * Roles granting impersonate or full control of roles/clusterroles.
        EOF
        echo

        echo "=== Namespaced RoleBindings using high-privilege ClusterRoles ==="
        if [[ -s /tmp/high_priv_roles.txt ]]; then
          for ns in $(kubectl get ns -o jsonpath='{range .items[*]}{.metadata.name}{"\n"}{end}'); do
            while read -r cr; do
              kubectl get rolebindings -n "$ns" -o jsonpath="{range .items[?(@.roleRef.kind=='ClusterRole' && @.roleRef.name=='$cr')]}${ns}|$cr|{.metadata.name}|{range .subjects[*]}{.kind}:{.apiGroup}:{.name},{end}{\"\n\"}{end}" 2>/dev/null
            done < /tmp/high_priv_roles.txt
          done | column -s"|" -t || true
        else
          echo "Skipped: no additional high-privilege ClusterRoles identified."
        fi
        echo
        cat <<'EOF'
        Interpretation:
        - Any subject listed here may have effective cluster-wide or very broad privileges.
        - Problems to review:
          * RoleBindings in application namespaces that attach to high-privilege ClusterRoles.
          * Wide or unmanaged subjects (e.g. large IdP groups).
        EOF
        echo

        echo "=== Summary guidance (MANUAL review required) ==="
        cat <<'EOF'
        Look for:
        - Human users or broad identity groups bound to cluster-admin or equivalent roles.
        - Service accounts outside system/control-plane usage with cluster-admin or near-equivalent access.
        - RoleBindings to cluster-admin or powerful ClusterRoles in non-system namespaces.

        If you find problematic bindings:
        - Use your cloud provider console / CLI / IaC (not kubectl alone) to adjust identity mappings and
          bindings according to your access-control design and the CIS OKE 5.1.2 guidance.
        EOF
        ```

        **What output indicates a problem**

        * Any human user or broad group listed as a subject of:
          * `cluster-admin` via `ClusterRoleBinding` or `RoleBinding` in any namespace.
          * Custom/high-privilege `ClusterRole` (wildcard `*` verbs, `impersonate`, or full control of roles/clusterroles).
        * RoleBindings to `cluster-admin` or such high-privilege ClusterRoles in regular (non-`kube-system` / non-control-plane) namespaces.
      </Accordion>
    </AccordionGroup>
  </Tab>
</Tabs>