Skip to main content

Minimize User Access Control To Container Engine For

More Info:​

Restrict user access to Container Engine for Kubernetes, limiting interaction to only authorized personnel and service accounts.

Risk Level​

High

Address​

Security

Compliance Standards​

  • APRA CPS 234 (Australia)
  • BSI C5 (Germany)
  • Brazil LGPD
  • CCPA / CPRA (California)
  • CIS Critical Security Controls v8
  • CIS OKE
  • CMMC 2.0
  • CSA Cloud Controls Matrix v4
  • DPDPA
  • Digital Operational Resilience Act (EU)
  • Essential 8
  • ISO/IEC 27017
  • ISO/IEC 27018
  • ISO/IEC 27701
  • KSA PDPL
  • MAS Technology Risk Management (Singapore)
  • MITRE ATT&CK (Cloud)
  • NIS2 Directive
  • NIST SP 800-171
  • NYDFS 23 NYCRR 500
  • SWIFT Customer Security Controls Framework
  • Sarbanes-Oxley IT General Controls
  • UK NCSC Cyber Assessment Framework

Triage and Remediation​

Remediation​

Manual Steps

  1. List all current Kubernetes RBAC bindings

    • Run on: any machine with kubectl access and cluster-admin-equivalent rights.
    kubectl get clusterrolebindings -o wide
    kubectl get rolebindings --all-namespaces -o wide
    • Identify any subjects (users, groups, service accounts) bound to cluster-admin or other highly privileged roles.

  2. Drill into high-privilege bindings and confirm necessity

    • For each suspicious/high-privilege binding (especially cluster-admin), inspect full details:
    kubectl get clusterrolebinding <BINDING_NAME> -o yaml
    kubectl get rolebinding -n <NAMESPACE> <BINDING_NAME> -o yaml
    • For each user/group/service account, confirm with your IAM/OCI tenancy records and owners whether they still require this level of access for operational duties.

  3. Cross‑check with Oracle Cloud Infrastructure IAM

    • In the OCI Console (or via OCI CLI/IaC), review:
      • Tenancy administrator groups and their policies.
      • Any groups that grant access to Container Engine for Kubernetes (OKE) clusters.
    • Confirm whether OCI tenancy administrators are relying on OCI-level privileges (recommended) rather than additional in‑cluster cluster-admin bindings.

  4. Decide reduced-scope RBAC where possible

    • For each subject that does not truly need cluster‑wide admin access:
      • Determine the minimal scope and verbs required (e.g., namespace‑scoped admin/edit, or a custom ClusterRole limited to specific API groups/resources).
    • Draft or adjust RBAC manifests (in Git/IaC if applicable) to reflect that reduced privilege before making changes in the live cluster.

  5. Apply RBAC changes to remove or narrow excessive access

    • To remove an unnecessary binding entirely:
    kubectl delete clusterrolebinding <BINDING_NAME>
    # or
    kubectl delete rolebinding -n <NAMESPACE> <BINDING_NAME>
    • To narrow access, first create/modify a less‑privileged role/clusterrole (via your IaC or change process), then bind it:
    kubectl apply -f <rbac-manifest.yaml>
    • Avoid granting cluster-admin except to a very small, justified set of break‑glass or platform operations identities.

  6. Verify the reduced access set

    • Re-run:
    kubectl get clusterrolebindings -o wide | grep -i cluster-admin || true
    kubectl get rolebindings --all-namespaces -o wide | grep -i cluster-admin || true
    • Confirm that:
      • Only the minimal, approved identities have cluster-admin.
      • All other users/groups/service accounts have appropriately scoped roles aligned with your policy and OCI tenancy design.
Using kubectl

kubectl cannot be used to change Container Engine for Kubernetes user access at the tenancy/OCI IAM level; the required changes occur in Oracle Cloud Infrastructure IAM and Container Engine for Kubernetes console/CLI/IaC configuration. Refer to the Manual Steps section for guidance on reviewing and adjusting user and group access, including assignment of the cluster-admin clusterrole only to explicitly authorized identities.

Automation
#!/usr/bin/env bash
# Report potentially over-privileged access (cluster-admin, image access) in an OKE cluster.
# Run on: any machine with kubectl access and appropriate auth context.

set -euo pipefail

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

echo "=== 1) ClusterRoleBindings granting cluster-admin ==="
kubectl get clusterrolebindings --no-headers 2>/dev/null | awk '{print $1}' | while read -r crb; do
  role_ref=$(kubectl get clusterrolebinding "$crb" -o jsonpath='{.roleRef.name}')
  if [ "$role_ref" = "cluster-admin" ]; then
    echo "ClusterRoleBinding: $crb"
    kubectl get clusterrolebinding "$crb" -o jsonpath='  Subjects: {.subjects[*].kind}{": "}{.subjects[*].name}{"\n"}'
  fi
done
echo
echo "# PROBLEM indication:"
echo "# - Any ClusterRoleBinding that grants cluster-admin to human users or broad groups"
echo "#   (e.g., kind=User with a real user name, kind=Group like \"Administrators\""
echo "#   or an IdP-wide group) should be reviewed. ServiceAccounts should be limited/"
echo "#   documented and ideally namespace-scoped for specific automation."
echo

echo "=== 2) Namespaced RoleBindings (by namespace) granting cluster-admin ==="
for ns in $(kubectl get ns -o jsonpath='{.items[*].metadata.name}'); do
  echo "Namespace: $ns"
  found=0
  for rb in $(kubectl get rolebindings -n "$ns" --no-headers 2>/dev/null | awk '{print $1}'); do
    role_ref=$(kubectl get rolebinding "$rb" -n "$ns" -o jsonpath='{.roleRef.kind}:{.roleRef.name}')
    if [ "$role_ref" = "ClusterRole:cluster-admin" ]; then
      found=1
      echo "  RoleBinding: $rb"
      kubectl get rolebinding "$rb" -n "$ns" -o jsonpath='    Subjects: {.subjects[*].kind}{": "}{.subjects[*].name}{"\n"}'
    fi
  done
  if [ "$found" -eq 0 ]; then
    echo "  (no RoleBindings to cluster-admin)"
  fi
done
echo
echo "# PROBLEM indication:"
echo "# - Any RoleBinding in application namespaces that references ClusterRole cluster-admin"
echo "#   for users, groups, or service accounts is likely excessive and should be minimized."
echo

echo "=== 3) ServiceAccounts with access to registry/image pull secrets (by namespace) ==="
for ns in $(kubectl get ns -o jsonpath='{.items[*].metadata.name}'); do
  echo "Namespace: $ns"
  sa_list=$(kubectl get sa -n "$ns" --no-headers 2>/dev/null || true)
  if [ -z "$sa_list" ]; then
    echo "  (no ServiceAccounts)"
    continue
  fi
  while read -r _sa_name _rest; do
    sa_name=$(awk '{print $1}' <<<"$_sa_name $_rest")
    image_secrets=$(kubectl get sa "$sa_name" -n "$ns" -o jsonpath='{.imagePullSecrets[*].name}' 2>/dev/null || true)
    if [ -n "$image_secrets" ]; then
      echo "  ServiceAccount: $sa_name"
      echo "    imagePullSecrets: $image_secrets"
    fi
  done <<<"$sa_list"
done
echo
echo "# PROBLEM indication:"
echo "# - ServiceAccounts with powerful imagePullSecrets that grant access to sensitive"
echo "#   or tenant-wide registries should be tightly scoped and not broadly used for"
echo "#   user workloads or across many namespaces."
echo

echo "=== 4) Subjects bound to cluster-admin that look like human users ==="
echo "# This uses a simple heuristic: subjects of kind=User or Group."
kubectl get clusterrolebindings -o json | \
  jq -r '
    .items[]
    | select(.roleRef.name=="cluster-admin")
    | .metadata.name as $crb
    | .subjects[]
    | select(.kind=="User" or .kind=="Group")
    | "ClusterRoleBinding=\($crb) kind=\(.kind) name=\(.name)"' 2>/dev/null || true
echo
echo "# PROBLEM indication:"
echo "# - Any line above is a candidate for review. Human users and broad groups"
echo "#   should not generally hold cluster-admin in production OKE clusters."
echo

echo "=== Review guidance (no automatic changes performed) ==="
echo "# 1) For each cluster-admin binding, determine if it is required for:"
echo "#      - OKE/OCI tenancy admin operations, or"
echo "#      - specific cluster automation that truly needs full control."
echo "# 2) For non-essential bindings, plan to:"
echo "#      - Replace cluster-admin with narrower ClusterRoles;"
echo "#      - Use namespace-scoped Roles/RoleBindings where possible;"
echo "#      - Keep imagePullSecrets and ServiceAccounts tightly scoped."
echo "# 3) Changes to these bindings and IAM are done via OCI Console/CLI/IaC,"
echo "#    not via this script."

How to interpret the output (what indicates a problem)

  • Any ClusterRoleBinding or RoleBinding that references cluster-admin and lists:

    • kind: User with real user identities, or
    • kind: Group representing broad identity-provider groups, or
    • generic ServiceAccounts used by many workloads
      should be treated as potentially excessive and reviewed.

  • ServiceAccounts with powerful imagePullSecrets used across multiple namespaces or by untrusted workloads indicate overly broad access to container images and should be minimized and documented.

Additional Reading:​