How to use Google's workload identity federation with AWS
Cloud admins struggle to share data between cloud providers. Here are the steps to create a federated identity in Google Cloud, connecting it to AWS in a secure way.
While a multi-cloud strategy has many advantages, it presents challenges when you access data across cloud providers. In particular, enterprises need a way to map identities across cloud boundaries.
With federated identity management, applications are able to share identity information and authenticate users across multiple domains without many login processes.
Let's take a look at the benefits of workload identity federation, as well as how to create a federated identity in Google Cloud. The specific details here apply to AWS and Google Cloud. However, the principles of federated identity management work in other combinations of cross-cloud access control.
What is workload identity federation?
Cloud admins on Google Cloud commonly use service accounts to facilitate a multi-cloud environment. Service accounts are identities with privileges to access and operate on resources in Google Cloud. These accounts are associated with processes or workloads rather than individual users. A user on another cloud provider can invoke the service account to perform some action on their behalf. For example, a user can retrieve a file from object storage or run a data analysis pipeline.
Service accounts get the job done. But they are long-lived, and depend on protection from the cloud admin to avoid letting in attackers. Attackers can compromise the authentication information for the service account, which is typically in the form of keys.
Workload identity federation is a better alternative to access AWS data with Google Cloud. It eliminates the need to store credentials for service accounts outside of Google Cloud. Rather than long-lived service accounts, this approach uses short-lived federated identity tokens.
Review the pros and cons of federated identity management.
Workload identity federation is a keyless application authentication mechanism in Google Cloud. It follows the OAuth 2.0 token exchange protocol. Users, via an external identity provider such as AWS Identity and Access Management, present a credential to Google's Security Token Service (STS). The STS validates the credential and returns a federated identity token to authenticate requests within Google Cloud.
Credentials usually include attributes that assert properties of the identity, such as a name, email address or membership in certain groups or roles. Workload identity federation maps external attributes to Google Cloud-specific attributes. It provides a default set of attributes automatically mapped, but cloud admins can configure custom mappings as well.
What are workload identity pools?
External identities are managed in groups known as workload identity pools. Workload identity pools can impersonate any number of service accounts. In general, create separate workload identity pools for each environment: development, test, production or other segments. Aim for only one AWS account per workload identity pool.
Consider managing federated identities in code, because admins can review, deploy and version control code as needed.
Cloud administrators can create workload identity pools using Google Cloud Console or programmatically using an API or command line utility. Consider managing federated identities in code, because admins can review, deploy and version control code as needed.
Google Cloud associates identity providers with workload identity pools. A workload identity provider is a system component. This entity describes a relationship between Google Cloud and an external identity provider, such as AWS or Azure Active Directory. Once you create a workload identity pool and establish a provider, external identities can impersonate service accounts.
The gcloud iam service-accountsadd-iam-policy-binding command creates the impersonation relationship that is at the core of this approach to workload identity federation. The command specifies that the role -- roles/iam.workloadIdentityUse -- is bound to a service account. The role applies to a set of specified workload identity pool members. Members can be all identities in the pool, or a subset of members. The add-iam-policy-binding command supports:
specific AWS users
all identities in the pool
all identities within a specific AWS role
all identities with an attribute value
Establish a federated identity
The goal of identity federation is to allow an external AWS user or role to impersonate a Google Cloud service account. Three high-level steps are required to establish a federated identity using Google Cloud's workload identity federation feature.
Step 1. Enable service APIs.
As with other Google services, the process begins by enabling service APIs in the Google account. Start by enabling the Identity and Access Management, Resource Manager, Service Account Credentials and Security Token Service APIs.
Step 2. Allow AWS authentication.
Next, change the organization policy to allow for AWS authentication. Enable the constraint constraints/iam.workloadIdentityPoolProviders and specify https://sts.amazonaws.com as an allowed identity provider. You can also specify the AWS account IDs.
Figure 1. Change the policy constraint in Google Cloud.
In AWS, create an AWS role and note its Amazon Resource Name.
Figure 2. Create a role figure in AWS.
Step 3. Create the service account.
Finally, create a Google Cloud service account and grant it access to all services the federated identity needs to run its workloads or access specific resources.
Figure 3. Create service account in Google Cloud.
Dig Deeper on Cloud infrastructure design and management
