Source URL: https://cloud.google.com/blog/products/identity-security/make-iam-for-gke-easier-to-use-with-workload-identity-federation/
Source: Cloud Blog
Title: Make IAM for GKE easier to use with Workload Identity Federation
Feedly Summary: 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
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.
AI Summary and Description: Yes
Summary: The text discusses improvements in security practices for Google Cloud, specifically focusing on the transition from less secure authentication methods to more secure alternatives like Google Kubernetes Engine (GKE) Workload Identity. This change simplifies IAM configurations for Kubernetes workloads and enhances compliance with security principles such as least privilege, making it particularly relevant for security professionals.
Detailed Description:
The text highlights significant advancements in security configurations for Google Cloud, specifically relating to authentication methods for Google Kubernetes Engine (GKE). It emphasizes a shift away from older, less secure practices towards improved techniques that bolster security while simplifying user workload management. Here are the major points discussed in the text:
– **Improvement in Security Capabilities**: Google Cloud continuously aims to enhance its security features to provide users with more trusted cloud services.
– **Transition from Service Account Keys to More Secure Methods**:
– **Export Credentials**: Mounting credentials as secrets in Pods can be risky if keys are inadequately managed.
– **Node Service Account**: Sharing a worker node’s identity poses risks of excessive permissions, which contradicts the principle of least privilege.
– **GKE Workload Identity**: The recommended practice allows access to Cloud APIs using OpenID Connect with simpler configurations and enhanced security.
– **Simplification of IAM Policies**:
– Users can now directly reference GKE workloads and Kubernetes service accounts in IAM policies, which reduces the complexity previously faced with maintaining multiple accounts.
– This simplification reduces configuration steps and encourages a streamlined approach to managing identities.
– **Integrated Experience within Cloud IAM**:
– Kubernetes identities are now represented as first-class entities in Google Cloud IAM, allowing for easier management and application of least-privilege recommendations.
– **Support for PrincipalSet Notation**:
– This new notation allows referencing multiple GKE workloads within a single IAM policy, further simplifying permission management and compliance.
– **Limitations and Recommendations**:
– Users are alerted to certain limitations regarding specific Google Cloud services that may not yet support the new identity configurations.
– A push for users to update their existing configurations to align with the new simplified policies is made, along with helpful resources for guiding the transition.
– **Practical Implications**:
– By transitioning to GKE Workload Identity, organizations can better align with security best practices, particularly around the principle of least privilege, reducing risks associated with service account impersonation.
In summary, the update promotes better security posture within Google Cloud environments, advocating for a more efficient and less risk-prone method of managing identities and access controls for Kubernetes workloads. This information is vital for security and compliance professionals tasked with maintaining secure cloud environments.