You've deployed NetworkPolicies. Your containers run as non-root. Images are scanned. Your team is proud of the hardening work.
Then someone notices an old CI service account still has cluster-admin through a ClusterRoleBinding.
Security controls are not independent if an identity can change all of them.
Why cluster-admin matters
Kubernetes RBAC permissions are additive. A ClusterRoleBinding granting cluster-admin effectively provides full API control across the cluster. A RoleBinding to that ClusterRole grants permissions within its namespace instead—a distinction that matters when interpreting findings.
If a CI token, automation identity, or developer credential has excessive privileges, a compromise can reach far beyond the workload it originally served.
This doesn't mean every administrator account is automatically a vulnerability. It means broad privileges must be deliberate, limited, auditable, and justified.
Start by finding broad bindings
Read-only inspection:
kubectl get clusterrolebindings \
-o custom-columns=NAME:.metadata.name,ROLE:.roleRef.name
kubectl get rolebindings -A \
-o custom-columns=NAMESPACE:.metadata.namespace,NAME:.metadata.name,ROLE:.roleRef.name
Then trace the subjects in the relevant bindings. Distinguish human groups, built-in control-plane identities, and application or CI service accounts before deciding what to change.
For a specific identity, check effective rights using kubectl auth can-i, with impersonation only if your own account is authorized to perform that check.
What usually needs to change
- Replace broad permissions with task-specific Roles and RoleBindings where possible.
- Give automation its own identity; avoid reusing a human's kubeconfig in CI.
- Separate production deployment authority from day-to-day development access.
- Review permissions after an automation or vendor tool is decommissioned.
- Monitor privileged API actions and keep a documented break-glass process.
A CI job that updates one Deployment in one namespace rarely needs permission to edit Secrets in every namespace or modify cluster-wide authorization policy.
RBAC is one layer, not the entire security plan
Admission policies, network segmentation, workload identities, secrets management, and cloud IAM still matter. In cloud environments, review the mapping between identity-provider permissions and Kubernetes RBAC as well.
For a command-by-command review, see Auditing Kubernetes RBAC and the official RBAC documentation.
Discussion: Should production CI ever have cluster-admin, or are there cases where the trade-off is justified?
If you haven't reviewed identity scope recently, the Kubernetes Cluster Audit includes RBAC and access-control checks. Request an audit or a call.