How does EchelonGraph detect CIS Kubernetes 5.1.1 violations?

EchelonGraph automatically detects CIS Kubernetes 5.1.1 violations using scanner rule K8S-RBAC-001. The scanner checks cloud infrastructure configurations in real-time and flags non-compliant resources.

How do I remediate CIS Kubernetes 5.1.1?

kubectl delete clusterrolebinding \u003cname\u003e; replace with namespace-scoped RoleBindings or narrowly-scoped ClusterRoles.

What audit questions are asked for CIS Kubernetes 5.1.1?

List every ClusterRoleBinding to cluster-admin and the business justification for each subject. Is there an admission policy preventing cluster-admin grants outside system:* paths? How quickly can you revoke cluster-admin if a subject is compromised?

☸️CIS Kubernetes 5.1.1Rule: K8S-RBAC-001critical

Cluster-admin role usage minimised

Description

Cluster-admin role should not be granted to non-system subjects. The Tier 3 watcher inspects every ClusterRoleBinding subject list and flags those granting cluster-admin to users / groups / service accounts outside the system:* prefix.

⚠️ Risk Impact

A single ClusterRoleBinding to cluster-admin gives the bound subject full read/write/delete authority over every resource in the cluster — including the ability to mint new tokens, modify RBAC, and exfiltrate every Secret. Real-world breaches consistently start with one over-broad CRB.

🔍 How EchelonGraph Detects This

K8S-RBAC-001Automated scanner rule

EchelonGraph's Tier 1 Cloud Scanner automatically checks for this condition across all connected cloud accounts. Violations are flagged as critical-severity findings with remediation guidance.

🖥️ Manual Verification

terminal

kubectl get clusterrolebindings -o json | jq '.items[] | select(.roleRef.name=="cluster-admin") | .subjects'

🔧 Remediation

kubectl delete clusterrolebinding <name>; replace with namespace-scoped RoleBindings or narrowly-scoped ClusterRoles.

💀 Real-World Attack Scenario

A platform team granted cluster-admin to a 'developer-debug' group during a P1 incident and never revoked it. Six months later a compromised dev laptop's kubeconfig was used to install a malicious mutating admission webhook that exfiltrated every newly-created Secret to an attacker-controlled S3 bucket. Detected only after a quarterly audit ran our broad-RBAC scan.

📋 Audit Questions

1.List every ClusterRoleBinding to cluster-admin and the business justification for each subject.
2.Is there an admission policy preventing cluster-admin grants outside system:* paths?
3.How quickly can you revoke cluster-admin if a subject is compromised?

🎯 MITRE ATT&CK Mapping

T1078 — Valid AccountsT1098 — Account Manipulation

📈 Business Value

Continuous live RBAC inventory eliminates the 'documented at deploy time, drifted by quarter end' gap. EchelonGraph re-evaluates every CRB on every change.

🔗 Cross-Framework References

NIST-AC-6SOC2-CC6.2ISO27001-A.5.15

Automate CIS Kubernetes 5.1.1 compliance

EchelonGraph continuously monitors this control across all your cloud accounts.

Start Free →