cyber.hendryadrian.com
Security Report · securitylabs.datadoghq.com

Datadog Finds 3,500+ Dangerous Kubernetes RBAC Bindings Across 65,000 Clusters

· Original article ↗

Summary

Datadog analyzed more than 65,000 Kubernetes clusters and found over 3,500 bindings granting dangerous permissions to built-in principals, highlighting excessive RBAC access and configurations that may need review.

Key points

  • The study examined more than 65,000 clusters across nearly 10,000 organizations.
  • From over 320,000 bindings to built-in principals, Datadog excluded default bindings and obsolete Pod Security Policy bindings, leaving about 44,000 for analysis.
  • More than 3,500 bindings granted at least one permission the study classified as dangerous to principals such as system:anonymous or system:authenticated.
  • Anonymous-access protections vary by Kubernetes distribution: AKS disables anonymous authentication, while EKS and GKE restrict which endpoints can be accessed without credentials.
  • The study found obsolete Pod Security Policy bindings that no longer affect cluster behavior but may indicate RBAC configurations are not regularly maintained.
  • Some risky bindings are namespace-scoped; in multi-tenant clusters, namespace administrators may create bindings that expose broader cluster risks. Datadog recommends reviewing and tightening RBAC permissions.

Article Details

Publisher
Datadog Security Labs
Scope
Analysis of Kubernetes RBAC bindings granting permissions to system:anonymous, system:unauthenticated, and system:authenticated.
Sample Size
Over 65,000 clusters from almost 10,000 organizations.
Key Statistics
  • Over 320,000 bindings referenced the three built-in principals; excluding 265,000 default Kubernetes bindings left approximately 55,000 for analysis.
  • 11,000 bindings referenced podsecuritypolicy objects, a feature removed in Kubernetes v1.25.
  • After excluding default bindings and podsecuritypolicy-related bindings, 44,000 bindings remained.
  • Over 3,500 bindings granted at least one permission classified as dangerous at the RBAC level. Actual impact could be reduced by cluster posture, usage, or other controls.
Recommendations
  • Review and tighten excessive RBAC permissions granted to built-in principals according to least privilege.
  • Regularly maintain RBAC configurations and remove redundant bindings to simplify security administration and auditing.
  • Review namespace-scoped bindings as well as cluster-scoped bindings, particularly in multi-tenant clusters.
  • Verify distribution-specific anonymous-access controls rather than assuming security defaults apply universally.

Vendors

AmazonIn our dataset, most of the clusters ran on Amazon Elastic Kubernetes Service (Amazon EKS), Google Kubernetes Engine (GKE), or Microsoft's Azure Kubernetes Service (AKS), so it's worth mentioning the relevantGoogleIn our dataset, most of the clusters ran on Amazon Elastic Kubernetes Service (Amazon EKS), Google Kubernetes Engine (GKE), or Microsoft's Azure Kubernetes Service (AKS), so it's worth mentioning the relevantMicrosoftthe clusters ran on Amazon Elastic Kubernetes Service (Amazon EKS), Google Kubernetes Engine (GKE), or Microsoft's Azure Kubernetes Service (AKS), so it's worth mentioning the relevant access-control defaults for each

Products

Amazon Elastic Kubernetes ServiceIn our dataset, most of the clusters ran on Amazon Elastic Kubernetes Service (Amazon EKS), Google Kubernetes Engine (GKE), or Microsoft's Azure Kubernetes Service (AKS), so it's worth mentioning the relevantAzure Kubernetes ServiceAmazon Elastic Kubernetes Service (Amazon EKS), Google Kubernetes Engine (GKE), or Microsoft's Azure Kubernetes Service (AKS), so it's worth mentioning the relevant access-control defaults for each before gettingGoogle Kubernetes EngineIn our dataset, most of the clusters ran on Amazon Elastic Kubernetes Service (Amazon EKS), Google Kubernetes Engine (GKE), or Microsoft's Azure Kubernetes Service (AKS), so it's worth mentioning the relevantKubernetesKubernetes authorization is a vital but complex part of cluster security, where mistakes can have serious consequences in allowing attackers to establish and expand their access to critical resources.

Related Articles