Detections
Analytics

4.1.9 Avoid binding RBAC roles to all authenticated users

Information

Avoid non-default RoleBinding and ClusterRoleBinding objects that grant RBAC permissions to the system:authenticated group. This group represents all authenticated Kubernetes API requests from users signed in with a Google Account, including Gmail accounts, so it should not be used for custom access grants. The default system ClusterRoleBindings system:basic-user, system:discovery, and system:public-info-viewer are expected and should not be treated as findings by themselves.

Binding a Role or ClusterRole to system:authenticated grants the referenced permissions to a very broad set of authenticated identities instead of a specific user, group, or service account. This can unintentionally expose cluster resources to any authenticated Google Account, depending on the role being bound. RBAC permissions are additive, and access should be granted through specific subjects with only the API groups, resources, and verbs required for the task.

Non-default bindings to system:authenticated are especially risky when they include broad roles, wildcard permissions, Secret access, workload access, or namespace wide access. Where access is required, bind permissions to a defined Google Group, IAM service account, Kubernetes service account, or named user instead of the global system:authenticated group.

NOTE: Nessus has provided the target output to assist in reviewing the benchmark to ensure target compliance.

Solution

Remove any non-default binding to system:authenticated identified in the audit and replace it with explicit, least privilege access for specific authenticated subjects. Do not remove the expected default ClusterRoleBindings system:basic-user, system:discovery, or system:public-info-viewer . RBAC permissions should be granted through defined users, groups, or service accounts rather than the broad system:authenticated group.

 -

Review each non-default RoleBinding or ClusterRoleBinding returned by the audit and identify the referenced Role or ClusterRole

 -

Determine the specific API groups, resources, verbs, and namespace scope required for the affected users, tools, or automation

 -

Create or update a least privilege Role or ClusterRole that grants only the required access

 -

Bind the replacement role to a specific user, Google Group, IAM service account, or Kubernetes service account

 -

Delete the unsafe non-default binding to system:authenticated only after replacement access is validated

kubectl delete clusterrolebinding <clusterrolebinding-name>

kubectl delete rolebinding <rolebinding-name> -n $NAMESPACE

Impact:

Removing non-default bindings to system:authenticated can affect users, tools, or automation that implicitly relied on broad authenticated access. Before removal, review the referenced Role or ClusterRole, identify the required API groups, resources, and verbs, and replace the binding with least privilege access for specific authenticated subjects. Do not delete the default system ClusterRoleBindings system:basic-user, system:discovery, or system:public-info-viewer, because required system RBAC resources support normal cluster functionality.

See Also

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

Item Details

Category: ACCESS CONTROL

References: 800-53|AC-2, CSCv7|16.8

Plugin: GCP

Control ID: 73671fd7e6f306cf81b72fe74474ea55219cd2c22ac0c3ea89403bc401747e44