Skip to main content

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

High

Address

Security

Compliance Standards

  • CIS GKE

Triage and Remediation

Remediation

Manual Steps

  1. 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.
  2. 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.
  3. Deny or delete any pending/approved CSRs using system:masters
    • For a CSR you want to explicitly deny:
    • Or to delete it entirely:
  4. Revoke or remove any existing credentials that include O = system:masters outside 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.
  5. 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:masters in certificates:
    • In the editor, remove or correct the subject that referenced that certificate identity.
  6. Verification: confirm no CSRs request system:masters
    • On any machine with kubectl access:
    • The control is satisfied when only NO_SYSTEM_MASTERS_CREDENTIALS_FOUND is printed.
On any machine with kubectl access:
  1. Identify CSRs requesting system:masters
For each CSR name you see, inspect it:
If the output shows:
that CSR is requesting system:masters and its resulting credential must not be used.
  1. Deny or delete offending CSRs
For CSRs that have not yet been approved and should not be used:
Optionally also delete them:
  1. Revoke already-approved system:masters credentials
For CSRs already approved (look for Approved in .status.conditions):
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.
  1. Prevent future issuance with O=system:masters
Update your certificate issuance process (outside of kubectl) so that CSRs for Kubernetes client certs do not set 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.
  1. Verification
Run the benchmark audit logic with kubectl (on any machine with kubectl access):