Perils of GKE’s “system:authenticated” Group
Google Kubernetes Engine (GKE) users, beware: a recent Orca Security report, published on January 24th, 2024, unveils a concerning aspect of GKE cluster authentication and authorization that could potentially open the door to unauthorized access. This vulnerability stems from a common misunderstanding about the “system:authenticated” group within GKE, which, alarmingly, encompasses all authenticated users, including anyone with a basic Google account.
The Core of the Issue
The crux of the problem lies in GKE’s inclusive definition of the “system:authenticated” group. This group includes not only service accounts but also individual users with Google accounts, such as Gmail. This design means that any Google user could potentially exploit their OAuth 2.0 bearer token to gain authentication to a GKE cluster.
The above diagram from Orca Security illustrates how threat actors could leverage this flaw to their advantage.
Mitigating the Risk
In light of this revelation, it’s paramount for GKE users to exercise extreme caution when assigning RBAC permissions, particularly to the “system:authenticated” group. Although GKE by default doesn’t grant expansive permissions to this group, the potential for oversight remains.
Google has taken steps to mitigate this risk by restricting the assignment of the “cluster-admin” role to specific groups in GKE 1.28. However, this doesn’t eliminate the possibility of assigning other roles and permissions to the “system:authenticated” group.
The Reality of Upgrades and Continuous Monitoring
Many GKE users operate on older versions of the platform, where upgrading to newer releases might introduce breaking changes. This makes the upgrade process a significant undertaking, emphasizing the importance of regular monitoring for RBAC drift. Ideally, this monitoring should be continuous, but at a minimum, weekly checks are advisable.
A Call to Diligence
This situation underscores a critical aspect of cloud service providers’ shared responsibility model. Users must remain vigilant in managing their RBAC permissions to safeguard their Kubernetes environments against potential threats. This issue isn’t slated for a design change, making user vigilance and proactive management more crucial than ever.
Summary
For GKE users, this development is a clarion call to reassess and tighten their cluster’s security posture, especially regarding RBAC permissions. Even for those not on GKE, this serves as a valuable lesson in the importance of scrutinizing and managing access controls within Kubernetes infrastructures.
Leave a Reply