GKE Sys:All Loophole: Don’t let shared responsibility lull you into a false sense of security

A recent discovery by The Orca Research Pod named ‘Sys:All’ presents an impactful and widely spread vulnerability in Google Cloud Platform’s Kubernetes Engine. 

The loophole & its implications.

This misconfiguration or misconception derives from usage of a ‘system:authenticated’ group, which includes any Google account that has authenticated to the Kubernetes API server disregarding the authentication method used, including the ones outside of the organisation. 

As this group is bound sometimes unknowingly with a wide set of permissions, it can significantly increase the attack surface of Google Kubernetes Engine environment. 

Even though Google has now taken measures and blocked the binding of the ‘system:authenticated’ group into ‘cluster-admin’ role in GKE versions 1.28 onwards, this behaviour was considered intentional on Google’s part and many other roles and permissions are still assignable for this group.

Orca Research Pod’s estimation is that over 1 million Google Kubernetes Engine clusters are affected by this vulnerability.

The case provides a real life lesson on two paramount concepts in cloud security.

Always grant access rights according to the Principle of Least Privilege. Access control related vulnerabilities can be mitigated most effectively when no unnecessary roles and permissions are bound to widely used groups such as ‘system:authenticated’ and when the access rights and permissions are granted as granularly as possible and always on need basis. 

If in doubt, refer to the original documentation to avoid possible misconceptions that might lead to overly permissive accesses and unintentional bindings.

The other lesson is that it’s extremely important to deeply understand the shared responsibility model of the services that you utilise in your public cloud environment. As said, according to Google this was intentional functionality of Google Kubernetes Engine and in the shared responsibility model the configuration of access controls falls on customers shoulders in this case.

Assess the misconfigurations & vulnerabilities of your cloud environment with constant evaluation.

To fight against threats and vulnerabilities in the public cloud you should assess the risk in every stage of the development life-cycle. To review the level of security in your managed Kubernetes environment, you can use a benchmark such as the one provided by The Center for Internet Security (CIS). 

A benchmark-based security assessment can help you to define the areas of improvement in your managed Kubernetes environment against globally recognised best practices. It also gives you practical and detailed guidance on how to configure your environment to be more strong in defence (GKE CIS documentation). 

To achieve a healthy level of security in the cloud, a deep understanding of your cloud environment and its building blocks is required. But in the end, it’s all about continuous learning and improvement. Discoveries like ‘Sys:All’ offer a great chance to revisit the knowledge gained and understand the nuances of cloud security better.