More Info:
The system:masters group is hardcoded into the API server and bypasses RBAC entirely. Credentials granting membership in this group should be removed.Risk Level
HighAddress
SecurityCompliance Standards
- CIS GKE
Triage and Remediation
- Remediation
Remediation
Manual Steps
Manual Steps
-
Identify certificates that request membership in
system:masters- On any machine with kubectl access:
- Note any CSRs you see; the verification in step 6 will confirm if any are using
O = system:masters.
- On any machine with kubectl access:
-
Inspect each suspicious CSR and confirm
O = system:masters- Replace
<csr-name>with each CSR from step 1: - If the Subject contains
O = system:masters, treat that credential as over‑privileged.
- Replace
-
Deny or delete any pending/approved CSRs using
system:masters- For a CSR you want to explicitly deny:
- Or to delete it entirely:
- For a CSR you want to explicitly deny:
-
Revoke or remove any existing credentials that include
O = system:mastersoutside of CSRs- Locate the client certificate/key file(s) used by that user or component (kubeconfig entries, TLS files on disk) and remove or replace them with new credentials that do not include
O = system:masters. - This step is environment‑specific and may involve updating kubeconfig files and rotating certificates; ensure the replacement credentials are bound only to appropriate RBAC groups/ServiceAccounts.
- Locate the client certificate/key file(s) used by that user or component (kubeconfig entries, TLS files on disk) and remove or replace them with new credentials that do not include
-
Ensure no ClusterRoleBindings are granting cluster‑admin via
system:masters-style certs- On any machine with kubectl access:
- For any binding that is intended for those removed certificates, remove or adjust the binding to use explicit users/groups/ServiceAccounts instead of relying on
O = system:mastersin certificates: - In the editor, remove or correct the subject that referenced that certificate identity.
- On any machine with kubectl access:
-
Verification: confirm no CSRs request
system:masters- On any machine with kubectl access:
- The control is satisfied when only
NO_SYSTEM_MASTERS_CREDENTIALS_FOUNDis printed.
- On any machine with kubectl access:
Using kubectl
Using kubectl
On any machine with kubectl access:For each CSR name you see, inspect it:If the output shows:that CSR is requesting Optionally also delete them:Use your PKI/CA tooling to identify and revoke the corresponding certificate at the certificate authority. Then ensure any kubeconfig or secret that uses this certificate is removed or rotated. This step cannot be completed with kubectl alone; follow your PKI’s revocation process.
- Identify CSRs requesting
system:masters
system:masters and its resulting credential must not be used.- Deny or delete offending CSRs
- Revoke already-approved
system:masterscredentials
Approved in .status.conditions):- Prevent future issuance with
O=system:masters
O=system:masters. For any remaining automation that still creates such CSRs, disable or fix it, then deny/delete those CSRs as in step 2.- Verification
Automation
Automation

