GCP – Make IAM for GKE easier to use with Workload Identity Federation
At Google Cloud, we work to continually improve our platform’s security capabilities to deliver the most trusted cloud. As part of this goal, we’re helping our users move away from less secure authentication methods such as long-lived, unauditable, service account keys towards more secure alternatives when authenticating to Google Cloud APIs and services.
In the context of Kubernetes workloads, there have been three ways users can do this:
-
Export credentials and mount as a secret in the Pod at runtime. This is done using service account keys but could be a security risk if the keys are not managed correctly.
-
Use the worker node identity or credential, such as the node service account. The security issue is that the credential is shared by all workloads deployed on that node. This can result in over-provisioning of permissions, which violates the principle of least privilege and is not recommended for multi-tenant clusters nor microservices in general.
-
Use GKE Workload Identity, which allows you to grant access to Cloud APIs using OpenID Connect without needing manual configuration or less secure methods like the aforementioned options.
The preferred option has been to use GKE Workload Identity. Earlier this year, we renamed it Workload Identity Federation for GKE, and rolled out a significant update that made it even easier to use. The update also enabled deeper integration into Google Cloud’s IAM platform. Here’s what you need to know about the changes.
- aside_block
- <ListValue: [StructValue([(‘title’, ‘$300 in free credit to try Google Cloud security products’), (‘body’, <wagtail.rich_text.RichText object at 0x3e43faea9ac0>), (‘btn_text’, ‘Start building for free’), (‘href’, ‘http://console.cloud.google.com/freetrial?redirectPath=/welcome’), (‘image’, None)])]>
Why you should avoid service account impersonation (for most cases)
Previously, a workload on GKE needed to impersonate a Google Cloud service account with its Kubernetes service account (KSA) in order to enable Pod access to Google Cloud services. Although this improved security, we heard from many users that it was difficult to set up. Having to maintain both a Kubernetes service account and a Google Cloud service account for every Kubernetes workload also contributed to a sprawl of identities that needed to be managed and audited.
While the previous configuration is still possible and will continue to be supported, there is now a simpler way to configure this access: Google Cloud IAM policies can directly reference GKE workloads and Kubernetes service accounts. This significantly simplifies the setup (six configuration steps to three), removing the need to manage another set of Google Cloud service accounts, and perform annotations on Kubernetes service accounts referencing the Google Cloud service account.
More integrated experience inside Cloud IAM
Moving towards this new configuration also gives your Kubernetes identities first class principal and principalSet representations inside Google Cloud IAM. When you use IAM tools such as IAM recommender and IAM policies, you no longer need to apply changes to the impersonated service account and then mentally map the service account to the Kubernetes workload.
For example, inside the IAM recommender you can now directly see least privileged recommendations for your Kubernetes workloads and apply these recommendations directly to the Kubernetes principal.
Referencing multiple GKE workloads inside IAM using principalSet notation
Previously, you could only reference a single principal (such as a single Kubernetes service account). The new configuration supports the principalSet notation which enables an attribute-based selection of multiple identities just like any other Workload Identity Federation principal. As a result, you can now refer to multiple GKE workloads in a single IAM policy, for example:
1) All workloads or Pods that belong to a Kubernetes namespace.
- code_block
- <ListValue: [StructValue([(‘code’, ‘principalSet://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/PROJECT_ID.svc.id.goog/namespace/NAMESPACE’), (‘language’, ”), (‘caption’, <wagtail.rich_text.RichText object at 0x3e43faf16640>)])]>
2) All workloads or Pods that belong to a Kubernetes cluster.
- code_block
- <ListValue: [StructValue([(‘code’, ‘principalSet://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/PROJECT_ID.svc.id.goog/kubernetes.cluster/https://container.googleapis.com/v1/projects/PROJECT_ID/locations/LOCATION/clusters/CLUSTER_NAME’), (‘language’, ”), (‘caption’, <wagtail.rich_text.RichText object at 0x3e43faf0bb20>)])]>
Limitations and next steps
There are still a few limitations when using this capability that you should be aware of. If any of these apply, you will need to continue to use the previous service account impersonation method to perform authentication:
-
A small number of Google Cloud services don’t yet support Workload and Workforce Identity Federation principals.
-
VPC Service Controls ingress and egress rules do not support Workload Identity Federation principal and principalSets.
-
The specific permission to invoke a Cloud Run instance does not support Workload Identity Federation principal and principalSets.
We encourage you to update your existing configurations and use this new simplified IAM policy syntax where you can, moving forward.
To get started, consult the following guidance:
- View our updated documentation (Concept, How-to) pages and update your configurations.
- Check out our Container Native Security Con lighting talk on removing the need for impersonation.
- Check out our Container Bytes video on Workload Identity Federation for GKE.
Read More for the details.
