Minimize User Access Control To Container Engine For Kubernetes

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