Members of the system:masters group bypass all RBAC checks. Unlike a user bound to cluster-admin, you cannot revoke their access by deleting a RoleBinding or ClusterRoleBinding. Keep the group for bootstrap and break-glass use, and give people ordinary roles that can be audited and removed.
What the docs say
The RBAC good practices page advises avoiding adding users to system:masters. Any user in the group bypasses all RBAC rights checks, and removing RoleBindings or ClusterRoleBindings cannot revoke their access. If you use an authorization webhook, membership in the group also bypasses the webhook.
The RBAC reference gives the legitimate use. When you need to bootstrap permissions, you use a credential with the system:masters group, which the default bindings tie to the cluster-admin super-user role.
Why it is a different kind of risk
A cluster-admin binding is an object. You can list it, diff it, delete it and see it in review. Membership of system:masters is a property of the credential. A client certificate, for example, carries its group in the subject, so the cluster has no binding to remove. Revoking it means dealing with the credential itself, which can be much harder than deleting an object.
I am describing a general property of certificate credentials here. Check your distribution's documentation for how its admin kubeconfig is issued and rotated.
Where it tends to appear
- The admin kubeconfig created when a cluster is built.
- Shared credentials that were handed to "the platform team" and copied around.
- Old automation that was given the admin kubeconfig because it was convenient.
What to do
- Find out which credentials carry the group. Start with your cluster build tooling and any shared kubeconfig files.
- Store the bootstrap credential offline, with a documented break-glass process and a log of each use.
- Give daily admin work to named users or groups bound to cluster-admin or, better, to narrower roles. Those bindings can be reviewed and removed.
- Use impersonation for accidental-change protection: the docs note that a low-privileged account with impersonation rights can prevent accidental changes.
- Rotate the bootstrap credential after anyone who held it leaves.
Why not just use cluster-admin for everyone
The docs say not to use cluster-admin accounts unless specifically needed. It is the same advice at a smaller scale. The difference is that a cluster-admin grant can at least be seen and revoked as an RBAC object.
Safeguard works outside the cluster here. Compliance and evidence automation can hold the record of who has break-glass access and when it was last reviewed, and policies and gates can check manifest changes. It does not manage cluster credentials.
A short audit you can run this week
Ask three people on your platform team where the admin kubeconfig lives, who has a copy and when it was last rotated. If the three answers differ, you have found the problem. Write the agreed answer down, and make it part of the offboarding checklist so that a departure triggers rotation of anything the person could reach.
Quick check
Can I remove someone from system:masters by deleting their binding?
No. The docs say removing RoleBindings or ClusterRoleBindings cannot revoke access for members of the group.
Sources
Last reviewed: 19 October 2026.
