Minimize User Access Control To Container Engine For

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

Remediation

Remediation

Manual Steps

1. List all subjects bound to cluster-admin and other powerful roles

   • Run on: any machine with kubectl access to the cluster
   • Command:

     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):

     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:

     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):

     # 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):

     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.

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.

Automation

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