Skip to main content

Access Control And Container Engine For Kubernetes

More Info:​

Manage Kubernetes RBAC users and grant clusterroles on a cluster deployed on Oracle Cloud Infrastructure as appropriate.

Risk Level​

Low

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. Identify which users should have cluster-wide admin on this cluster

    • On any machine with OCI Console access, review your OCI identity model and decide which OCI users or groups must administer Kubernetes (for example, a small ops group, not all tenancy admins). Document their OCI user OCIDs or group principals.

  2. List current cluster-admin bindings and mapped OCI principals

    • On any machine with kubectl access (using your own kubeconfig for this cluster): 
      kubectl get clusterrolebindings -o wide
      kubectl get clusterrolebindings -o yaml > /tmp/clusterrolebindings.yaml
    • In /tmp/clusterrolebindings.yaml, look for subjects that reference:
      • clusterrole: cluster-admin in roleRef
      • kind: User, kind: Group, kind: ServiceAccount and note any values that correspond to OCI user OCIDs or groups.

  3. Compare existing cluster-admin access to your intended model

    • For each clusterrolebinding with roleRef.name: cluster-admin, check whether the user, group, or serviceAccount subject:
      • Is an intended Kubernetes admin (from step 1), or
      • Is overly broad (e.g., large groups, system service accounts, or generic users).
    • Flag any bindings that grant cluster-admin to unintended or unknown subjects.

  4. Remove or restrict unintended cluster-admin bindings

    • On any machine with kubectl access, for each binding you decide is too broad or not justified: 
      kubectl delete clusterrolebinding <binding-name>
    • If you only need to narrow subjects (for example, changing to a smaller group), delete the old binding and then recreate a corrected one (step 5).

  5. Grant cluster-admin only to explicitly approved OCI users/groups

    • For each approved OCI user that needs full admin: 
      kubectl create clusterrolebinding <descriptive-binding-name> \
        --clusterrole=cluster-admin \
        --user=<user_OCID>
    • If you use OCI groups/OIDC or other identity providers mapped as Kubernetes Groups, create bindings using --group=<group-name> instead, matching your IAM design.

  6. Verify final cluster-admin assignments

    • On any machine with kubectl access: 
      kubectl get clusterrolebindings cluster-admin -o yaml 2>/dev/null || true
      kubectl get clusterrolebindings -o yaml | grep -A5 "roleRef:" | grep -B2 "cluster-admin"
    • Confirm that all remaining cluster-admin bindings reference only the intended OCI users/groups or service accounts, and that any previously identified excessive access has been removed.
Using kubectl

kubectl cannot change this finding because it is controlled by the Oracle Cloud Infrastructure managed control plane and cluster / cloud provider configuration, not by in-cluster Kubernetes API objects. Use the Oracle Cloud Console, OCI CLI, or your IaC tooling to manage access control as described, and refer to the Manual Steps section for the concrete review and remediation process.

Automation
#!/usr/bin/env bash
# Purpose: Report all clusterrolebindings that grant cluster-admin, and
#          list which OCI users/groups/serviceaccounts have that access.
# Run on: Any machine with kubectl access to the target cluster.
# Requirements: kubectl, jq

set -euo pipefail

echo "=== Checking connectivity and permissions ==="
kubectl auth can-i list clusterrolebindings >/dev/null 2>&1 || {
  echo "ERROR: Current identity cannot list clusterrolebindings. Exiting." >&2
  exit 1
}

echo
echo "=== Summary: identities with cluster-admin privileges ==="
# List all subjects (user, group, serviceaccount) that get cluster-admin
kubectl get clusterrolebindings -o json \
  | jq -r '
    .items[]
    | select(.roleRef.kind=="ClusterRole" and .roleRef.name=="cluster-admin")
    | .metadata.name as $crb
    | ( .subjects // [] )[]
    | [$crb, .kind, (.namespace // "-"), .name]
    | @tsv' \
  | awk 'BEGIN {
           printf "%-40s %-15s %-25s %-60s\n",
                  "CLUSTERROLEBINDING", "SUBJECT_KIND", "NAMESPACE", "SUBJECT_NAME"
           print sprintf("%0.s-", "", 145)
         }
         {
           printf "%-40s %-15s %-25s %-60s\n", $1, $2, $3, $4
         }'

echo
echo "=== Detailed JSON for all cluster-admin bindings (for audit/review) ==="
kubectl get clusterrolebindings \
  -o jsonpath='{range .items[?(@.roleRef.kind=="ClusterRole" && @.roleRef.name=="cluster-admin")]}{"---\n"}{.metadata.name}{"\n"}{.subjects}{"\n\n"}{end}'

echo "=== Notes: How to interpret this output ==="
cat <<'EOF'
Potential problems to investigate:
1) Unexpected USERS with cluster-admin:
   - SUBJECT_KIND=User where SUBJECT_NAME looks like an OCI user OCID
     (e.g., ocid1.user.oc1..aaaa...).
   - Confirm each such user truly requires full cluster-wide admin.

2) Broad GROUP or system:masters access:
   - SUBJECT_KIND=Group with generic or organization-wide groups.
   - Any mapping that effectively gives many people cluster-admin
     should be risk-reviewed.

3) SERVICEACCOUNTS with cluster-admin:
   - SUBJECT_KIND=ServiceAccount (NAMESPACE != "-").
   - Service accounts rarely need full cluster-admin; this is
     usually over-privileged.

4) Orphaned/legacy bindings:
   - Bindings created for past migrations, tests, or ex-employees.
   - If a binding is no longer needed, plan to remove it manually.

This script does NOT change anything. Use it regularly and review
each identity with cluster-admin to decide if it is justified.
EOF

Additional Reading:​