How to create an identity federation between GCP and AWS using Tines

In this guest blog post, Marcus Hallberg and Attila Dulovics, senior security engineers at Spotify, share a Tines workflow they built to create identity federation between GCP and AWS.

As modern organizations continue their journey into the cloud, they face the complex reality of a mix of cloud providers and on-premise infrastructure. This often happens due to acquisitions being made, necessary partner integrations, or other business and technical requirements that create a multi-cloud setup over time. 

This is where identity federation can become a valuable tool, where we can use explicit trust relationships to allow resources in one cloud environment to access resources in another.
We can define identity federation as:

Identity federation: Federated identity allows authorized users to access resources in different cloud environments using a single set of credentials. It links a user's identity across multiple identity management systems so that they can access different applications securely and efficiently.

With all of this in mind, let’s explore how we can use Tines to achieve secure identity federation cross-cloud.

How do we configure identity federation? 

In practice, identity federation is exchanging one authorized identity for another, based on pre-established trust. This means we need to allow one authorized identity to exchange its credentials for another cloud provider’s identity, which gives them permission to carry out the necessary actions. For example, if we want to gain access in AWS while our service has its own GCP workload identity (e.g a service account), we can generate a webIdentity token that is issued by and uses Google’s Open ID Connect infrastructure. 

To get a better understanding, let’s pick one specific example, enabling a Google service account to list AWS S3 buckets without any static credentials. 

In order for us to achieve this access between GCP and AWS, we need the following components:

1. A GCP service account with the IAM permissions to create tokens. 

2. Additionally, we can also grant other GCP identities and users the permissions to impersonate the service account. 

3. An AWS IAM role with a condition that allows the GCP service account to assume it, using the oaud statement.

Once we have these components defined, we can grant access between the GCP service account and AWS IAM role in the following way:

1. Create a request token for the GCP service account.

2. This can be done either by using a GCP service account key or user credentials that allows impersonation of the service account. 

3. Request an access token for the GCP service account.

4. Request an OpenID Connect (OIDC) identity token for the GCP service account (using the acquired access token from step 3).

5. As we now have an active OIDC token that contains the necessary identity information of the GCP service account, we can make a request to the AWS STS service for the IAM role via the AssumeRoleWithWebIdentity STS option.

A approximate view of this flow is shown below:

Below you can also see a complete definition of what that AWS IAM Role statement looks like.

[
 {
   "Effect": "Allow",
   "Principal": {
     "Federated": "accounts.google.com"
   },
   "Action": "sts:AssumeRoleWithWebIdentity",
   "Condition": {
     "StringEquals": {
       "accounts.google.com:oaud": GCP_SERVICE_ACCOUNT_OAUD_DEFINED_AUDIENCE,
       "accounts.google.com:email": GCP_SERVICE_ACCOUNT_EMAIL,
       "accounts.google.com:sub": GCP_SERVICE_ACCOUNT_EMAIL_UNIQUE_ID
     }
   }
 },
 {
   "Effect": "Allow",
   "Principal": {
     "Service": "s3.amazonaws.com"
   },
   "Action": "sts:AssumeRole"
 }
]

Note: there are other methods for federating access in GCP, such as workload identity. 

Conclusion 

Following the example above, we’ve shown how we can leverage a single GCP service account to federate access and set up trust for an AWS IAM role, and, by doing so, connect the two cloud environments using a single identity. This provides a seamless integration and opens up a range of opportunities for reducing service account keys and creating explicit trust, as well as new opportunities for cross-cloud automations. The use cases for this span from cloud security incident response and forensics to regular cross-cloud task automation and access.

The following Github repository and Tines story provide a complete testing setup to try this out yourself.