Darkbit has joined Aqua Security!

...

Google Kubernetes Engine IAM Roles

14 January 2021

As a Google Cloud Administrator planning your IAM strategy for how to best use the built-in Google Kubernetes Engine (GKE) IAM Roles, there are a few details that might be confusing and/or surprising that could have unintended consequences.

Clarifying the GKE Predefined IAM Roles

GKE Built-in Roles listing

Here’s a listing of the predefined IAM Roles for Kubernetes Engine purposes, their official descriptions (as of the time of this writing), and a few notes on potential areas for confusion:

Potential Risks and Privilege Escalation Paths

  1. Kubernetes Engine Viewer
    • Having container.pods.list (and cronjobs, deployments, jobs, and statefulsets list) and container.configMaps.list can potentially leak sensitive credentials and/or details from pod environment variables or what is stored in configMaps. Note that viewing secrets is not allowed by this role.
  2. Kubernetes Engine Developer
    • Having container.secrets.list allows reading secrets contents in all namespaces in the GKE cluster, including kube-system. Kubernetes secrets are also where Kubernetes serviceaccount tokens are stored, so a “Developer” is actually the union of all permissions granted to all serviceaccounts in the cluster. If a controller like Anthos Config Management, GKE Config Sync, Weaveworks’ Flux, or Helm v2 is deployed or any serviceaccount was manually bound to the cluster-admin ClusterRole, a direct path to reading those JWT tokens from their secrets resource and using them to authenticate against the API server is possible and very likely in most GKE clusters. We previously wrote about the power of LIST permissions in this related blog post that covers this scenario in greater detail.

Diving into Kubernetes Engine Admin vs Developer

The following list of permissions are available to the Kubernetes Engine Admin IAM Role that are not directly assigned to the Kubernetes Engine Developer IAM Role, but those in bold are what can potentially be gained back via the previously mentioned container.secrets.list escalation path:

Conclusion

Be aware that the name of these GKE IAM Roles can be confusing and potentially risky if applied without a deeper understanding of their usage in combination with other configuration settings like GKE Basic Authentication and RBAC ClusterRoleBindings. Our recommendation is to ensure GKE Basic Authentication isn’t in place and to handle authorization for users via native RBAC permissions in-cluster. This allows permissions to be granted to a subset of the clusters in the project and at the per-namespace level which provides the ideal levels of granularity.

Blog photo by heylagostechie on Unsplash