Detections
Analytics

4.1.6 Avoid use of system:masters group

Warning! Audit Deprecated

This audit has been deprecated and will be removed in a future update.

View Next Audit Version

Information

The special group system:masters should not be used to grant permissions to any user or service account, except where strictly necessary (e.g. bootstrapping access prior to RBAC being fully available)

The system:masters group has unrestricted access to the Kubernetes API hard-coded into the API server source code. An authenticated user who is a member of this group cannot have their access reduced, even if all bindings and cluster role bindings which mention it, are removed.

When combined with client certificate authentication, use of this group can allow for irrevocable cluster-admin level credentials to exist for a cluster.

GKE includes the CertificateSubjectRestriction admission controller which rejects requests for the system:masters group.

CertificateSubjectRestriction "This admission controller observes creation of CertificateSigningRequest resources that have a spec.signerName of kubernetes.io/kube-apiserver-client. It rejects any request that specifies a 'group' (or 'organization attribute') of system:masters." https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/#certificatesubjectrestriction

Solution

Remove the system:masters group from all users in the cluster.

Impact:

Once the RBAC system is operational in a cluster system:masters should not be specifically required, as ordinary bindings from principals to the cluster-admin cluster role can be made where unrestricted access is required.

See Also

https://workbench.cisecurity.org/benchmarks/24112

Item Details

Category: ACCESS CONTROL

References: 800-53|AC-6(2), 800-53|AC-6(5), CSCv7|4

Plugin: GCP

Control ID: aaf16ffdd41800724251b141fe62fc49d6e85c38d6e650802e91eb9afd8847d5