Detections
Analytics

4.1.8 Avoid binding RBAC roles to unauthenticated users and groups

Information

Avoid RoleBinding or ClusterRoleBinding objects that grant permissions to the system:anonymous user or the related system:unauthenticated group. These subjects represent unauthenticated Kubernetes API requests and should not receive RBAC access to cluster resources.

Kubernetes uses system:anonymous for requests that do not provide authentication credentials, and unauthenticated requests can also be associated with the system:unauthenticated group. Binding RBAC roles to either subject can grant unauthenticated callers access to Kubernetes API resources. This is especially risky if the binding includes broad roles, wildcard permissions, Secret access, workload access, or namespace wide permissions.

GKE can limit anonymous authentication so unauthenticated requests are rejected for non health check endpoints before RBAC evaluation. Even with that protection available, RBAC bindings to system:anonymous or system:unauthenticated should be avoided because they create unnecessary exposure and undermine least privilege access.

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

Solution

Remediate any RoleBinding or ClusterRoleBinding returned by the audit by removing unauthenticated access and replacing it with authenticated, least privilege RBAC access. Bindings to system:anonymous or system:unauthenticated should not be used for normal cluster operations because they can grant Kubernetes API permissions to unauthenticated requests.

 -

Review each returned binding and identify the referenced Role or ClusterRole, including the API groups, resources, and verbs granted

 -

Delete unnecessary bindings to system:anonymous or system:unauthenticated after confirming they are not required for cluster operation.

kubectl delete clusterrolebinding <clusterrolebinding-name>

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

 -

Replace any required access with authenticated users, groups, or dedicated Kubernetes service accounts using least privilege Role or ClusterRole permissions

 -

Do not replace unauthenticated access with broad roles, wildcard permissions, Secret access, or namespace wide permissions unless explicitly required and documented

Impact:

Removing bindings to system:anonymous or system:unauthenticated can affect workloads, scripts, or integrations that incorrectly rely on unauthenticated Kubernetes API access. Before removal, validate that required access uses an authenticated user, group, or service account with least privilege RBAC permissions.

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: 582a29bfd38708c56290f0dc498ff9fa9159a57c3831c0cd2e0406b42c37f6e5