Guarding the gates: Assessing dangerous permissions granted to Kubernetes built-in principals

What it is

Datadog Security Labs counted RBAC bindings to system:anonymous, system:unauthenticated and system:authenticated across more than 65,000 clusters from almost 10,000 organizations. The page gives the funnel behind the headline numbers and the version boundaries that decide whether an anonymous binding has any effect.

How it works

Any request without credentials is assigned the user system:anonymous and the group system:unauthenticated. Permissions granted to those subjects therefore apply to anyone who can reach the API server over the network. system:authenticated covers every user with valid credentials.

The binding funnel:

• Over 320,000 bindings to the three principals.
• 265,000 removed as Kubernetes defaults (system:basic-user, system:discovery, system:public-info-viewer), leaving about 55,000.
• 11,000 removed as podsecuritypolicy bindings, leaving 44,000. Pod Security Policies were removed in Kubernetes v1.25 (August 2022), so their presence suggests RBAC is not being maintained.
• Over 3,500 of the remaining bindings granted at least one permission on Datadog's "dangerous" list. Some were namespace-scoped.

Preconditions / Affected

Whether an anonymous binding matters depends on the distribution:

• AKS: runs with --anonymous-auth=false, so anonymous bindings have no effect.
• EKS: since v1.32, unauthenticated access is limited to a restricted set of endpoints, so anonymous bindings have no effect.
• GKE: allows anonymous access but limits the endpoints from v1.35. By default, any holder of a valid Google account counts as system:authenticated on any GKE cluster. Blocking arbitrary Google accounts is possible at cluster creation, but is not the default.
• Upstream Kubernetes: v1.34 added a feature to restrict anonymous access to a list of paths regardless of RBAC.

Namespace-scoped bindings matter most in "namespace as a service" multi-tenant clusters, where a namespace admin can bind to system:unauthenticated and expose the wider cluster.

What to do

The page gives no commands. Its advice is to review and tighten bindings to these three principals, remove stale ones (including podsecuritypolicy leftovers), and not rely on distribution defaults, since they differ. On self-managed clusters, --anonymous-auth=false or the v1.34 path restriction closes the anonymous route. Binding system:authenticated to anything beyond public information is unlikely to meet least privilege.

Caveats

• The page's list of dangerous permissions did not come through in the fetched text, so it is not reproduced here.
• Datadog says the dangerous count is hard to define, because cluster posture and other controls can reduce the impact. The 3,500 figure covers RBAC-level permissions only.
• 3,500 is a small share of the original 320,000 bindings.