Kubernetes RBAC Privilege Auditor

Threat/Impact Level: CRITICAL | Exploitability/Downtime Risk: HIGH | Time to Fix: 15 mins

TL;DR

• What broke: A ClusterRoleBinding is binding cluster-admin to a service account that should not have it, and one or more Role/ClusterRole definitions contain verbs: ['*'], granting unrestricted API access cluster-wide.
• How to fix it: Delete the offending ClusterRoleBinding, create a scoped Role in the target namespace with explicit verb allowlists, and bind it via a RoleBinding — never a ClusterRoleBinding — to the service account.
• Shortcut: Use our Client-Side Sandbox above to auto-refactor this — paste your RBAC manifest and get a least-privilege replacement generated locally without your configs leaving the browser.

SECURITY ALERT: ClusterRoleBinding 'pipeline-admin-binding' grants
ClusterRole 'cluster-admin' to ServiceAccount 'ci-runner'
in namespace 'build'. Severity: CRITICAL.

SECURITY ALERT: ClusterRole 'app-operator-role' contains
wildcard verbs ['*'] on apiGroups ['*'] resources ['*'].
This is functionally equivalent to cluster-admin. Severity: CRITICAL.

How to Fix It (The Solution)

Basic Fix — Remove the cluster-admin ClusterRoleBinding immediately

# Identify all ClusterRoleBindings granting cluster-admin to non-system accounts
kubectl get clusterrolebindings -o json | \
  jq '.items[] | select(.roleRef.name=="cluster-admin") | {name: .metadata.name, subjects: .subjects}'

# Delete the offending binding
kubectl delete clusterrolebinding pipeline-admin-binding

This is your immediate stop-the-bleeding action. Do it before writing replacement manifests.

Enterprise Best Practice — Least-Privilege Scoped RBAC

Replace the ClusterRoleBinding + cluster-admin pattern with a namespace-scoped Role + RoleBinding that grants only what the CI runner actually needs.

The bad configuration:

- apiVersion: rbac.authorization.k8s.io/v1
- kind: ClusterRoleBinding
- metadata:
-   name: pipeline-admin-binding
- roleRef:
-   apiGroup: rbac.authorization.k8s.io
-   kind: ClusterRole
-   name: cluster-admin          # ROOT ACCESS — never for CI runners
- subjects:
- - kind: ServiceAccount
-   name: ci-runner
-   namespace: build

The wildcard ClusterRole:

- apiVersion: rbac.authorization.k8s.io/v1
- kind: ClusterRole
- metadata:
-   name: app-operator-role
- rules:
- - apiGroups: ["*"]            # All API groups — unacceptable
-   resources: ["*"]            # All resources — unacceptable  
-   verbs: ["*"]                # All verbs — functionally cluster-admin

The hardened replacement:

+ # Step 1: Scoped Role — only in the 'build' namespace, only what CI needs
+ apiVersion: rbac.authorization.k8s.io/v1
+ kind: Role
+ metadata:
+   name: ci-runner-role
+   namespace: build              # Namespace-scoped, not cluster-wide
+ rules:
+ - apiGroups: [""]              # Core API group only
+   resources: ["pods", "pods/log"]
+   verbs: ["get", "list", "watch", "create", "delete"]
+ - apiGroups: ["apps"]
+   resources: ["deployments"]
+   verbs: ["get", "list", "patch", "update"]  # No 'delete', no '*'
+ ---
+ # Step 2: RoleBinding — NOT ClusterRoleBinding
+ apiVersion: rbac.authorization.k8s.io/v1
+ kind: RoleBinding
+ metadata:
+   name: ci-runner-binding
+   namespace: build
+ roleRef:
+   apiGroup: rbac.authorization.k8s.io
+   kind: Role
+   name: ci-runner-role
+ subjects:
+ - kind: ServiceAccount
+   name: ci-runner
+   namespace: build
+ ---
+ # Step 3: Disable automount on the ServiceAccount unless explicitly needed
+ apiVersion: v1
+ kind: ServiceAccount
+ metadata:
+   name: ci-runner
+   namespace: build
+ automountServiceAccountToken: false  # Mount manually in pod spec only when required

Key principles enforced here:

• Role + RoleBinding instead of ClusterRole + ClusterRoleBinding — blast radius is now one namespace
• Explicit verb allowlist — get, list, watch, create, delete, patch, update — never *
• automountServiceAccountToken: false at the ServiceAccount level; opt-in per pod
• Zero access to secrets, nodes, clusterrolebindings, or namespaces resources

💡 Tired of pasting proprietary infrastructure configs into public LLMs? Generic AI interfaces log your company's ARNs, connection strings, and private keys. StackEngine enforces client-side zero-trust boundaries—the sandbox above executes 100% locally in your browser. Drop your broken manifest above to redact secrets locally and synthesize deterministic patch drafts with your own API key.

(For CI/CD pipeline automation, install via npm i -g stackengine).

# ConstraintTemplate: deny ClusterRoleBindings to cluster-admin for non-system subjects
package k8sclusteradminbinding

violation[{"msg": msg}] {
  input.review.kind.kind == "ClusterRoleBinding"
  input.review.object.roleRef.name == "cluster-admin"
  subject := input.review.object.subjects[_]
  not startswith(subject.name, "system:")
  msg := sprintf("ClusterRoleBinding grants cluster-admin to non-system subject: %v", [subject.name])
}

# Install and run against your manifests directory
pip install checkov
checkov -d ./k8s-manifests --framework kubernetes \
  --check CKV_K8S_49  # Ensure no wildcard verbs
  --check CKV_K8S_155 # No cluster-admin bindings to service accounts

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: deny-wildcard-verbs
spec:
  validationFailureAction: Enforce
  rules:
  - name: deny-wildcard-verbs-in-roles
    match:
      resources:
        kinds: ["Role", "ClusterRole"]
    validate:
      message: "Wildcard verbs are not permitted in Role definitions."
      deny:
        conditions:
          any:
          - key: "{{ request.object.rules[].verbs[] | contains(@, '*') }}"
            operator: Equals
            value: true

# Run rbac-tool or kubectl-who-can on a schedule
kubectl-who-can '*' '*'  # Shows all subjects with wildcard permissions

# Or use rbac-lookup
kubectl rbac-lookup ci-runner --kind ServiceAccount --output wide