Shield GKE’s Achilles Heel using RBAC

If you’re using GKE (Google Kubernetes Engine), you should be extremely cautious when adding roles to the system:authenticated group because anyone with a Gmail account can access your cluster.

Introduction

On January 24th, 2024, Orca security researchers published a report exposing a largely unknown behavior in GKE clusters. Google’s design of cluster authentication and authorization implementation could lead to threat actors accessing and exploiting GKE clusters due to users’ confusion regarding the scope of “system:authenticated” group definitions.

The following diagram depicts how this flaw can be exploited:

The system:authenticated group in GKE includes all authenticated entities, that includes regular users with a simple Google account (for example Gmail) as well as service accounts. This by-design feature means that every user with a Google account can abuse their Google OAuth 2.0 bearer token to authenticate to your cluster and then abuse it.

To mitigate this users should be very careful with their RBAC (Role-Based Access Control) permissions that are bound to the groups system:anonymous, system:unauthenticated, system:authenticated.

Using ARMO platform’s RBAC visualizer, users can actually see that by default, create RBAC permissions are set for the group system:authenticated on GKE on less permissive roles.

While GKE doesn’t automatically grant any dangerous permissions. It remains crucial to manage user permissions carefully. That’s why Google has disabled assigning the powerful cluster-admin role to specific groups in GKE 1.28.

However, as Orca noted in its report: “…it’s important to note that this still leaves many other roles and permissions that can be assigned to the group.”

In addition, many users of GKE are running on much earlier versions of GKE. Upgrading may involve breaking changes that need to be accounted for, so this is a significant effort. Even if you start today, it can take a while.

Mitigation

A common recommendation is to check for RBAC drift at least weekly, if you don’t have continuous monitoring in place. 

The good news is that on the heels of this flaw being announced, a new Kubescape control C-0265 has been implemented on ARMO platform. It proactively warns users of this type of sensitive permissions, during a compliance scan. A scan which can be automated and even embedded in your CI/CD pipeline.

Below is an example of a scan using control C-0265 on Kubescape:

Conclusion

It’s important to note that this particular feature in GKE is designed intentionally and at this point in time is not subject to change. Herein lies a real-world example of the need to be very attentive to all CSPs’ shared responsibility model. Therefore, it’s crucial for GKE users, and indeed all Kubernetes users, to meticulously manage their RBAC permissions, adhering to the recommended best practices. This approach will help mitigate potential security risks associated with this feature.

ARMO is here to help with ARMO Platform’s RBAC visualizer, as well as its quick response to the developments that affect Kubernetes security. If you are running GKE, try ARMO Platform today, to make researching and mitigating this loophole easier, so you can get to mitigation faster.

If you aren’t using GKE, you can still reap the security benefits of uncovering overprivileged accounts and roles in your Kubernetes infrastructure.

Unifying AppSec, CloudSec and DevSec

The only runtime-driven, open-source first, cloud security platform:

Continuously minimizes cloud attack surface

Secures your registries, clusters and images

Protects your on-prem and cloud workloads

Powered by Kubescape & eBPF

See ARMO in Action