Cross-Cloud Authentication

By James MacGowan
on April 14, 2023

Workload Identity Federation

Workload Identity Federation is a new term that represents the ability to allow an internet attached workload to authenticate and access resources provided by another internet attached service or workload using existing identity provided to the workload. In other words, allow access to something outside of your environment without using a separate set of stored credentials. The source workload can be a resource in a public cloud, a cloud-based software platform, or even a custom application running on-premise. We are going to focus on use case of one cloud’s resource accessing a different cloud’s resources. This article will provide you with a way to have a resource in one cloud access resources in another cloud without having to store credentials or worry about locking down access using a whitelist of IP addresses.

It is now possible to use this form of authentication and authorization from either of the three main public clouds (AWS, Azure, and GCP) to each other. You can even use this for accessing another organization within the same cloud. The problem is that there really isn’t much documentation out there on how to do this. Google is the only cloud provider that has provided complete documentation on this process. Microsoft is starting to add some documentation for accessing GCP and AWS from Azure. Even if you know this functionality exists, you may still not know what to search for. The term, Workload Identity Federation, is very broad and technical. The reason is because this method of authentication has some very wide-ranging use cases and isn’t specific to authenticating across public clouds, but that is what we are going to focus on today.

OpenID Connect

This new method of workload authentication and authorization makes use of OpenID Connect. OpenID Connect is a simple identity layer on top of the OAuth 2.0 protocol, that many use for authorizing end-users. This new layer allows target platforms to verify the identity of a source user or workload based on the authentication performed by a web service, the Authorization Server. It is accessed by way of a pre-determined URL that the is known to the target identity platform. During the process, basic information is passed on to the target platform to aid in verifying the workload’s identity.

When configuring the target side for allowing a specific workload, you would require a few pieces of information.

Provider/Issuer URL - This is a specific web site URL that supports authenticating OpenID Connect requests.
Audience - This may represent the user/workload making the request but could also represent a higher-level identity such as the organization.
Subject - This identifies the workload.

When authenticating, the source workload will use its existing authentication to get a temporary token from its own identity provider and pass that on to the target platform along with any identifying information. The target platform will pass back a temporary access token to be used on all future requests.

Granting identity to resources

Without the ability to grant identity to a cloud resource, we would still have to store the credentials that would be used to generate the OpenID Connect token. All three public clouds have supported this ability for many years and the insecure practice of storing credentials on a VM should have been abolished from practice many years ago, but alas, that is not the case.

Methods of attaching identity on each cloud

AWS - IAM Instance Profiles / IAM Roles

Instance profiles are something that has become more hidden from view. They are still required as a go-between resource when assigning an IAM role to an EC2 instance but are not required when assigning an IAM role to other types of compute resources (ECS task, App Runner, EKS pods). When assigned, a temporary set of access keys and access token will be generated and assigned to environment variables. AWS CLI and other SDKs will use these environment variables automatically. This temporary credential will be re-created constantly throughout a day, so any application using them should always pull the latest values from the environment variables instead of caching the values within application variables.

Azure - Managed Identity

Managed Identity, formerly call Managed Service Identity (MSI), are a middle layer between the resource and an Azure Active Directory service principal. A matching service principal will be created when a managed identity is created. There are system-assigned and user-assigned managed identities. The difference is that user-assigned managed identities create a stand-alone Azure resource that can be managed directly by the user and can be shared across multiple Azure resources. System-assigned managed identities are tied to a single resource and can’t be changed. Managed Identities can be attached to most Azure resources and will grant permission to that resource to access other resources or external services. To use the managed identity from within a VM or container, you would request a token from the internally available metadata endpoint and pass that token along when accessing Azure interfaces.

GCP - Service Accounts

There are two types of service accounts, user-managed and Google-managed. The user-managed service accounts are the ones you can attach to a VM instance. To use the service account within the VM instance, you need to create a credential configuration file and set the GOOGLE_APPLICATION_CREDENTIALS environment variable to point to it. The file contains will contain details on where to obtain external credentials from, which workload identity pool and provider to use, and which service account to impersonate. The Google Cloud Client Libraries and gcloud CLI will automatically use this to authenticate.

Examples

As most examples found on the world wild web involve clicking through graphical interfaces, instead I have done up some command-line and scripting examples on how to authenticate across all 3 major public cloud providers using OpenID Connect. As web interfaces are constantly changing, these examples should age better and give a deeper understanding of how things work. Click on the buttons below to expand each example.

Choose one of the buttons above to see an example on how to authenticate from one cloud to another.

Accessing AWS resources from Azure

The ability to setup this trust is simple to config, but not well known. Any resource you can attach a managed identity to, will work as the source workload. The following will show you how to attach a system-assigned managed identity to an existing virtual machine. The same can be done for a function app, web app, container, or whatever else that supports managed identities and can be used to access AWS resources.

You could use a user-assigned managed identity, just make sure you store your managed identity resources in a separate protected resource group that most AD users do not have Contributor or higher access to. Anyone with access can generate tokens for the managed identity and impersonate the identity. This is why a system-assigned managed identity is preferred.

On the Azure side

You will need to configure the workload with a managed identity and retrieve its details.

We are going to use PowerShell on the Azure side as it is a bit easier to work with then the Azure CLI command. This means you will need to have PowerShell, the Az module, and the Az.ManagedServiceIdentity sub-module installed before running the following. We are going to use a VM as the example source workload.

$resourceName = "<name of your existing resource>"
$resourceGroup = "<resource group name>"
$location = (Get-AzResourceGroup -Name $resourceGroup).Location

# If the Virtual Machine doesn't already have a managed identity, use the following to add one.
$vm = Get-AzVM -ResourceGroupName $resourceGroup -Name $resourceName
Update-AzVm -ResourceGroupName $resourceGroup -VM $vm -IdentityType SystemAssigned

# Get the application ID and object ID for the managed identity.
$vm = Get-AzVM -ResourceGroupName $resourceGroup -Name $resourceName
Get-AzADServicePrincipal -ObjectId $vm.Identity.PrincipalId

Write down the ApplicationId (client ID) and Id (object ID) returned as we will need them when granting access within AWS.

On the AWS side

Create an IAM Identity Provider

There isn’t a nice way to accurately get the thumbprint for a provider URL, so we will do this step through the web console.

Login to the AWS console.
Go to IAM section.
Click on Identity Providers.
Click Add provider.
Choose OpenID Connect as the Provider type.
Paste in https://sts.windows.net/<tenant ID>/ as the Provider URL. Make sure you put in your Azure tenant ID. This allows you to lock down usage of this identity provider to only originate from the tenant ID.
Click on Get thumbprint.
For the Audience, paste in the client ID (application ID) of the managed identity attached to your source Azure resource (workload). If you are using a system managed identity, you will have to get the client ID (application ID) by searching for the managed identity under Azure AD / Enterprise Applications. If you are using a user-assigned managed identity you can find the details under the managed identities section of Azure.

Create an IAM role

You will need to create an IAM role with a trust relationship or assume role policy document that specifically allows the Azure user-assigned managed identity. The “aud” part is the audience that we added to the identity provider. For additional security we check that the subject (sub) matches the object ID of the managed identity. This trust policy will only allow a resource with the Azure managed identity access to assume this role.

We are going to use AWS CLI from a Linux command prompt for this part as that is the most used platform and method for accessing AWS from the command line. You can use Windows AWS CLI or PowerShell in a similar fashion. Creating the document files will be slightly different than the bash here-document (heredoc) syntax below.

Bash

cat << EOF > /tmp/iam-role-trustDoc.json
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "Federated": "arn:aws:iam::<AWS account ID>:oidc-provider/sts.windows.net/<Azure tenant ID>/"
            },
            "Action": "sts:AssumeRoleWithWebIdentity",
            "Condition": {
                "StringEquals": {
                    "sts.windows.net/<Azure tentant ID>/:aud": "<Managed identity client ID>",
                    "sts.windows.net/<Azure tentant ID>:sub": "<Managed identity object ID>"
                }
            }
        }
    ]
}
EOF

aws iam create-role --role-name target-workload --assume-role-policy-document file:///tmp/iam-role-trustDoc.json

cat << EOF > /tmp/iam-role-policyDoc.json
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "AllowListingOfBucketsOnly",
            "Effect": "Allow",
            "Action": [
                "s3:ListAllMyBuckets"
            ],
            "Resource": "*"
        }
    ]
}
EOF
aws iam attach-role-policy --role-name target-workload --policy-name S3-bucket-list-only --policy-document file:///tmp/iam-role-policyDoc.json

On the source workload

The following examples demonstrates how to access a target resource in AWS from a source resource in Azure. For production use, you would store the managed identity IDs and the target IAM role in a KeyVault and pull in the values when needed. For these examples you can add them inline. When you are on the VM, you can easily authenticated as the managed identity, it is just difficult to get the client ID of the managed identity without permission to do so. To simplify this, you could grant the managed identity Reader access to the VM resource and then read the managed identity client ID from the VM object.

PowerShell

Additional Requirements

Az module
AWS.Tools.Installer module
AWS.Tools.IdentityManagement module
AWS.Tools.S3 module

$ClientId = "<User managed identity client ID>"
$RoleArn = "arn:aws:iam::<AWS account ID>:role/<IAM role name>"

# Use managed identity attached to the VM to authenticate with Azure.
Connect-AzAccount -Identity

# Generate a temporary access token.
$Response = Get-AzAccessToken -Resource $ClientId

# Pass that token on to AWS along with the client ID, and the role to assume.
$Creds = Use-STSWebIdentityRole -RoleArn $RoleArn -RoleSessionName $ClientId -WebIdentityToken $Response.Token

Get-S3Bucket -Credential $Creds

Bash

Additional Requirements

clientId="<Managed identity client ID>"

# Use managed identity attached to the VM to authenticate with Azure.
az login --identity

# Generate a temporary access token.
token=$(az account get-access-token --resource $clientId --query "accessToken" --output tsv)

# Pass that token on to AWS along with the client ID, and the role to assume.
session=$(aws sts assume-role-with-web-identity --role-arn arn:aws:iam::<AWS account ID>:role/<IAM role name> --role-session-name $clientId --web-identity-token $token)

# Switch over to use the AWS session.
export AWS_ACCESS_KEY_ID="`echo $session | sed -n 's/.*"AccessKeyId":\s"\([^"]*\)",.*/\1/p'`"
export AWS_SECRET_ACCESS_KEY="`echo $session | sed -n 's/.*"SecretAccessKey":\s"\([^"]*\)",.*/\1/p'`"
export AWS_SESSION_TOKEN="`echo $session | sed -n 's/.*"SessionToken":\s"\([^"]*\)",.*/\1/p'`"

aws s3 ls

Python

Additional Requirements

from azure.identity import DefaultAzureCredential
import boto3

clientId = "<User managed identity client ID>"
roleArn = "arn:aws:iam::<AWS account ID>:role/<IAM role name>"

# Use managed identity attached to the VM to authenticate with Azure.
credential = DefaultAzureCredential(managed_identity_client_id=clientId)

# Generate a temporary access token.
response = credential.get_token(clientId)

# Pass that token on to AWS along with the client ID, and the role to assume.
sts = boto3.client('sts')
response = sts.assume_role_with_web_identity(
  RoleArn = roleArn,
  RoleSessionName = clientId,
  WebIdentityToken = response.token
)

# Switch over to use the AWS session.
session = boto3.Session(
  aws_access_key_id = response['Credentials']['AccessKeyId'],
  aws_secret_access_key = response['Credentials']['SecretAccessKey'],
  aws_session_token = response['Credentials']['SessionToken']
)
s3 = session.client('s3')
s3.list_buckets()

If the cross-cloud authentication worked, you should get a list of S3 buckets from the AWS account from your Azure VM without the need to store credentials that could leak and be used elsewhere.

Accessing AWS resources from GCP

Google has provided a good amount of documentation on how to do this process. If you have a slightly different setup, you might want to have a look at some of their examples.

Configure workload identity federation with AWS or Azure

We are going to use gcloud CLI from a Linux command prompt for this example as that is the most used platform and method for accessing GCP and AWS from the command line. You can use gcloud and AWS CLI commands from Windows in a similar fashion.

On the GCP side

You will need to configure a Compute Engine VM instance with a service account as your source workload. You can start with an existing instance, just make sure its service account has the cloud-platform scope.

Bash

projectId="<GCP project ID>"
serviceAccountName="<Your service account name>"

# Create a VM instance with the service account attached.
gcloud compute instances create example-vm \
    --service-account $serviceAccountName@$projectId.iam.gserviceaccount.com \
    --scopes cloud-platform

# Get the unique ID for the service account.
gcloud iam service-accounts describe $serviceAccountName@$projectId.iam.gserviceaccount.com

On the AWS side

Create an IAM Identity Provider

There isn’t a simple way to accurately get the thumbprint for the provider URL from the command-line, so we will do this step through the web console instead.

Login to the AWS console.
Go to IAM section.
Click on Identity Providers.
Click Add provider.
Choose OpenID Connect as the Provider type.
Paste in https://accounts.google.com as the Provider URL.
Click on Get thumbprint.
For the Audience, paste in the unique ID (client ID) of the GCP service account attached to your source workload GCP resource.
Create an IAM role

You will need to create an IAM role with a trust relationship (assume role policy document) that specifically allows the GCP service account.

cat << EOF > /tmp/iam-role-trustDoc.json
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "Federated": "arn:aws:iam::<AWS account ID>:oidc-provider/accounts.google.com"
            },
            "Action": "sts:AssumeRoleWithWebIdentity",
            "Condition": {
                "StringEquals": {
                    "accounts.google.com:aud": "<GCP service account unique ID>"
                }
            }
        }
    ]
}
EOF
aws iam create-role --role-name target-workload --assume-role-policy-document file:///tmp/iam-role-trustDoc.json

cat << EOF > /tmp/iam-role-policyDoc.json
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "AllowListingOfBucketsOnly",
            "Effect": "Allow",
            "Action": [
                "s3:ListAllMyBuckets"
            ],
            "Resource": "*"
        }
    ]
}
EOF
aws iam attach-role-policy --role-name target-workload --policy-name S3-bucket-list-only --policy-document file:///tmp/iam-role-policyDoc.json

On the source workload

The following examples demonstrates how to access a target resource in AWS from a source resource in GCP.

Bash

Additional Requirements

# There isn't a way to get the credentials client ID from the command line. The best way to get it is by decoding the token generated below and pulling it out of the "aud" field. You can decode a JWT token using https://jwt.io/. The client ID should look like ###########.apps.googleusercontent.com.
clientId="<GCP credentials client ID>"

# Generate a temporary access token.
token=$(gcloud auth print-identity-token)

# Pass that token on to AWS along with the client ID, and the role to assume.
session=$(aws sts assume-role-with-web-identity --role-arn arn:aws:iam::562047788754:role/OpenIdAzureTest --role-session-name $clientId --web-identity-token $token)

# Switch over to use the AWS session.
export AWS_ACCESS_KEY_ID="`echo $session | sed -n 's/.*"AccessKeyId":\s"\([^"]*\)",.*/\1/p'`"
export AWS_SECRET_ACCESS_KEY="`echo $session | sed -n 's/.*"SecretAccessKey":\s"\([^"]*\)",.*/\1/p'`"
export AWS_SESSION_TOKEN="`echo $session | sed -n 's/.*"SessionToken":\s"\([^"]*\)",.*/\1/p'`"

aws s3 ls

Python

Additional Requirements

import google.auth
import google.auth.transport.requests
from google.oauth2 import id_token
import boto3

roleArn = "arn:aws:iam::<AWS account ID>:role/<IAM role name>"
uniqueId = "<GCP service account unique ID>"

# Get credentials for service account attached to the instance.
credentials, project_id = google.auth.default()
request = google.auth.transport.requests.Request()
credentials.refresh(request)

# Generate a temporary access token.
token = id_token.fetch_id_token(request, "https://example.com")

# Pass that token on to AWS along with the client ID, and the role to assume.
sts = boto3.client('sts')
response = sts.assume_role_with_web_identity(
  RoleArn = roleArn,
  RoleSessionName = uniqueId,
  WebIdentityToken = token
)

# Switch over to use the AWS session.
session = boto3.Session(
  aws_access_key_id = response['Credentials']['AccessKeyId'],
  aws_secret_access_key = response['Credentials']['SecretAccessKey'],
  aws_session_token = response['Credentials']['SessionToken']
)

s3 = session.client('s3')
s3.list_buckets()

If the cross-cloud authentication worked, you should get a list of S3 buckets from the AWS account from your GCP instance without the need to store credentials that could leak and be used elsewhere.

Accessing Azure resources from AWS

AWS IAM/STS is not an OpenID Connect (OIDC) provider. GCP has built their own integration to allow AWS IAM users/roles to accessing GCP resources. There is another way to get this to work when Azure is the target. It involves using an additional AWS service for the OIDC provider, and that service is Cognito.

Cognito is overkill for what we need, but it is currently the only way to make this work. You will have to take extra precaution with restricting access to Cognito. If a user can generate the token, they can impersonate the workload.

On the AWS side

Creating Cognito Identity Pool

The terms developer provider and developer user are a little confusing for our use as Congito is designed to allow users to authenticate instead of workloads. We will refer to them as login provider and workload identifier. You can set them to whatever value you want to identify the target workload. They just need to match on both sides.

Bash

identityPool="AzureAccessFromAWS"
loginProvider="AwsInstances" # Unique name identifying the group of workloads
region="<AWS region>"

# Create a Cognito identity.
aws cognito-identity create-identity-pool --identity-pool-name $identityPool --no-allow-unauthenticated-identities --developer-provider-name $loginProvider --region $region

Grab the IdentityPoolId from the output as it will be needed for the next few steps.

Create IAM role

You will need to have an existing EC2 instance that you can access remotely using SSH.

We will create an IAM role, instance profile, and attach the instance profile/role to the EC2 instance. You will need to create an IAM role with a trust relationship (assume role policy document) that specifically allows the EC2 service to assume it.

accountId=$(aws sts get-caller-identity --query "Account" --output text)
region="<AWS region>"
identityPoolId="<Will be in the format of region:GUID>"
instanceId="<Your EC2 instance ID>"
roleName="ec2-access-azure"
$loginProvider = "ec2-instances"
$workloadIdentifier = "<workload identifier>"

cat << EOF > /tmp/iam-role-trustDoc.json
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "Service": "ec2.amazonaws.com"
            },
            "Action": "sts:AssumeRole"
        }
    ]
}
EOF

# Create IAM role and instance profile
aws iam create-role --role-name $roleName --assume-role-policy-document file:///tmp/iam-role-trustDoc.json
aws iam create-instance-profile --instance-profile-name $roleName
aws iam add-role-to-instance-profile --instance-profile-name $roleName --role-name $roleName

cat << EOF > /tmp/iam-role-policyDoc.json
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "AllowStsAccess",
            "Effect": "Allow",
            "Action": [
                "sts:GetSessionToken",
                "sts:GetFederationToken",
                "sts:GetAccessKeyInfo",
                "sts:GetCallerIdentity",
                "sts:GetServiceBearerToken"
            ],
            "Resource": "*"
        },
        {
            "Sid": "AllowCognitoAccess",
            "Effect": "Allow",
            "Action": [
                "cognito-identity:GetOpenIdTokenForDeveloperIdentity",
                "cognito-identity:LookupDeveloperIdentity",
                "cognito-identity:MergeDeveloperIdentities",
                "cognito-identity:UnlinkDeveloperIdentity"
            ],
            "Resource": "arn:aws:cognito-identity:$region:$accountId:identitypool/$identityPoolId"
        }
    ]
}
EOF
aws iam put-role-policy --role-name $roleName --policy-name auth-access --policy-document file:///tmp/iam-role-policyDoc.json

# Attach IAM instance profile to EC2 instance.
aws ec2 associate-iam-instance-profile --iam-instance-profile Name=$roleName --instance-id $instanceId

aws cognito-identity get-open-id-token-for-developer-identity --identity-pool-id $identityPool --logins "$loginProvider=$workloadIdentifier" --region $region

Grab the IdentityId from the output as it will be the subject for creating the Azure federated identity credentials.

On the Azure side

You have two options for what identity to use on the Azure side. You can use an AD App registration or a user-assigned managed identity. If you use user-assigned managed identities, you will want to create them in a dedicated resource group that only your security team has access to as anyone with Contributor access to a managed identity can generate a token from it.

AD App Registrations do not have this security issue but are a lot more complex for our needs.

Create User-Assigned Managed Identity

PowerShell

$subscription = Get-AzContext | Select Subscription
$identityName = "<Name identifying the source>"
$resourceGroup = "<Resource group name>"
$location = (Get-AzResourceGroup -Name $resourceGroup).Location
$issuer = "https://cognito-identity.amazonaws.com"
$subject = "<Cognito identity ID>"
$audience = "<Congito identity pool ID>"
$workloadIdentifier = "<Workload identifier>"

# Create user managed identity.
$identity = New-AzUserAssignedIdentity -ResourceGroupName $resourceGroup -Name $identityName -Location $location

# Create federated credentials for user managed identity.
New-AzFederatedIdentityCredentials -Name $workloadIdentifier -IdentityName $identity.Name -ResourceGroupName $resourceGroup -Issuer $issuer -Subject $subject -Audience $audience

# Assign the managed identity read access to the resource group.
New-AzRoleAssignment -ObjectId $identity.PrincipalId -RoleDefinitionName Reader -ResourceGroupName $resourceGroup

On the source workload

From the EC2 instance or ECS task run the following.

Bash

Additional Requirements

tenantId="<Azure tenant ID>"
clientId="<User managed identity client ID>"
region="<Congito region>"
identityPool="<Congito identity pool ID>"
loginProvider="ec2-instances"
workloadIdentifier="<Workload identifier>"

# Generate a Cognito identity and federated token.
token=$(aws cognito-identity get-open-id-token-for-developer-identity --identity-pool-id $identityPool --logins "$loginProvider=$workloadIdentifier" --region $region --query "Token" --output text)

# Pass that token on to Azure along with the tenant ID and client ID.
az login --federated-token $token --tenant $tenantId --service-principal -u $clientId

az resource list

If the cross-cloud authentication worked, you should get a list of Azure resources from your AWS instance without the need to store credentials that could leak and be used elsewhere.

Python

Additional Requirements

from azure.core.credentials import TokenCredential, AccessToken
from azure.identity import AzureAuthorityHosts
from azure.mgmt.resource import ResourceManagementClient
from msal import ConfidentialClientApplication
import boto3
import time

region = "<AWS region>"
tenantId = "<Azure tenant ID>"
subscriptionId = "<Azure subscription ID>"
clientId = "<User managed identity client ID>"
issuer = "https://cognito-identity.amazonaws.com"
identityPool = "<Congito identity pool ID>"
loginProvider = "ec2-instances"
workloadIdentifier = "<Workload identifier>"

cognito = boto3.client('cognito-identity', region_name = region)

# Generate a Cognito identity and federated identity token.
identity = cognito.get_open_id_token_for_developer_identity(
  IdentityPoolId = identityPool,
  Logins = {
    loginProvider: workloadIdentifier
  }
)

# Create a custom class that acts as a credential.
class AssertionCredential(TokenCredential):
  def __init__(self, client_id, tenant_id, id_token):
    self.app = ConfidentialClientApplication(
      client_id,
      client_credential={
        'client_assertion': id_token
      },
      authority=f"https://{AzureAuthorityHosts.AZURE_PUBLIC_CLOUD}/{tenant_id}"
    )
  def get_token(
    self,
    *scopes: str
  ) -> AccessToken:
    token = self.app.acquire_token_for_client(scopes)
    if 'error' in token:
      raise Exception(token['error_description'])
    expires_on = time.time() + token['expires_in']
    return AccessToken(token['access_token'], int(expires_on))

# Get a credential based on the identity token.
creds = AssertionCredential(
  tenant_id = tenantId,
  client_id = clientId,
  id_token = identity['Token']
)

# Get a list of resources from Azure
resource_client = ResourceManagementClient(creds, subscriptionId)
resources = resource_client.resources.list()

column_width = 36
print("Resource".ljust(column_width) + "Type".ljust(column_width))
print("-" * (column_width * 2))

for resource in list(resources):
  print(f"{resource.name:<{column_width}}{resource.type:<{column_width}}")

Accessing Azure resources from GCP

Google has provided a good amount of documentation on how to do this process. If you have a slightly different setup, you might want to have a look at some of their examples.

Configure workload identity federation with AWS or Azure

We are going to use gcloud CLI from a Linux command prompt for this example as that is the most used platform and method for accessing GCP from the command line. You can use gcloud CLI commands from Windows in a similar fashion.

On the GCP side

Here we will create a Compute Engine VM instance with a service account as your source workload. You can start with an existing instance. Just make sure its service account has the cloud-platform scope.

Bash

projectId="<GCP project ID>"
serviceAccountName="<Your service account name>"

# Create a VM instance with the service account attached.
gcloud compute instances create example-vm \
    --service-account $serviceAccountName@$projectId.iam.gserviceaccount.com \
    --scopes cloud-platform

# Get the unique ID for the service account.
gcloud iam service-accounts describe $serviceAccountName@$projectId.iam.gserviceaccount.com

On the Azure side

AD App Registrations do not have this security issue but are a lot more complex for our needs.

Create an Azure Managed Identity

PowerShell

$subscription = Get-AzContext | Select Subscription
$identityName = "<Name identifying the source>"
$resourceGroup = "<Resource group name>"
$location = (Get-AzResourceGroup -Name $resourceGroup).Location
$issuer = "https://accounts.google.com"
$subject = "<Service account unique/client ID>"
$audience = "<Service account email or instance name>"
$workloadIdentifier = "<Workload identifier>"

# Create user managed identity.
$identity = New-AzUserAssignedIdentity -ResourceGroupName $resourceGroup -Name $identityName -Location $location

# Create federated credentials for user managed identity.
New-AzFederatedIdentityCredentials -Name $workloadIdentifier -IdentityName $identity.Name -ResourceGroupName $resourceGroup -Issuer $issuer -Subject $subject -Audience $audience

# Assign the managed identity read access to the resource group.
New-AzRoleAssignment -ObjectId $identity.PrincipalId -RoleDefinitionName Reader -ResourceGroupName $resourceGroup

On the source workload

From the VM instance run the following.

Bash

Additional Requirements

tenantId="<Azure tenant ID>"
clientId="<User managed identity client ID>"

token=$(gcloud auth print-identity-token)

az login --federated-token $token --tenant $tenantId --service-principal -u $clientId
az resource list

If the cross-cloud authentication worked, you should get a list of Azure resources from your GCP instance without the need to store credentials that could leak and be used elsewhere.

Python

Additional Requirements

from azure.core.credentials import TokenCredential, AccessToken
from azure.identity import AzureAuthorityHosts
from azure.mgmt.resource import ResourceManagementClient
from msal import ConfidentialClientApplication
import google.auth
import google.auth.transport.requests
from google.oauth2 import id_token
import time

region = "<AWS region>"
tenantId = "<Azure tenant ID>"
subscriptionId = "<Azure subscription ID>"
clientId = "<User managed identity client ID>"
audience = "<Service account email or instance name>"

# Get a federated identity token.
credentials, project_id = google.auth.default()
request = google.auth.transport.requests.Request()
credentials.refresh(request)
id_token = id_token.fetch_id_token(request, audience)

# Create a custom class that acts as a credential.
class AssertionCredential(TokenCredential):
  def __init__(self, client_id, tenant_id, id_token):
    self.app = ConfidentialClientApplication(
      client_id,
      client_credential={
        'client_assertion': id_token
      },
      authority=f"https://{AzureAuthorityHosts.AZURE_PUBLIC_CLOUD}/{tenant_id}"
    )
  def get_token(
    self,
    *scopes: str
  ) -> AccessToken:
    token = self.app.acquire_token_for_client(scopes)
    if 'error' in token:
      raise Exception(token['error_description'])
    expires_on = time.time() + token['expires_in']
    return AccessToken(token['access_token'], int(expires_on))

# Get a credential based on the identity token.
creds = AssertionCredential(
  tenant_id = tenantId,
  client_id = clientId,
  id_token = id_token
)

# Get a list of resources from Azure
resource_client = ResourceManagementClient(creds, subscriptionId)
resources = resource_client.resources.list()

column_width = 36
print("Resource".ljust(column_width) + "Type".ljust(column_width))
print("-" * (column_width * 2))

for resource in list(resources):
  print(f"{resource.name:<{column_width}}{resource.type:<{column_width}}")

Accessing GCP resources from AWS

Google has provided a good amount of documentation on how to do this process. If you have a slightly different setup, you might want to have a look at some of their examples.

Configure workload identity federation with AWS or Azure

On the AWS side

Create IAM role

You will need to have an existing EC2 instance that you can access remotely using SSH.

We will create an IAM role, an IAM instance profile, and attach the instance profile/role to the EC2 instance. You will need to create an IAM role with a trust relationship (assume role policy document) that specifically allows EC2 service to assume it.

Bash

instanceId="<Your EC2 instance ID>"
roleName="source-workload"

cat << EOF > /tmp/iam-role-trustDoc.json
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "Service": "ec2.amazonaws.com"
            },
            "Action": "sts:AssumeRole"
        }
    ]
}
EOF
aws iam create-role --role-name $roleName --assume-role-policy-document file:///tmp/iam-role-trustDoc.json
aws iam create-instance-profile --instance-profile-name $roleName
aws iam add-role-to-instance-profile --instance-profile-name $roleName --role-name $roleName

cat << EOF > /tmp/iam-role-policyDoc.json
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "AllowGeneratingToken",
            "Effect": "Allow",
            "Action": [
                "cognito-identity:GetOpenIdTokenForDeveloperIdentity"
            ],
            "Resource": "<ARN of your Cognito identity pool>"
        },
        {
            "Sid": "AllowStsAccess",
            "Effect": "Allow",
            "Action": [
                "sts:GetSessionToken",
                "sts:GetFederationToken",
                "sts:GetAccessKeyInfo",
                "sts:GetCallerIdentity",
                "sts:GetServiceBearerToken"
            ],
            "Resource": "*"
        }
    ]
}
EOF
aws iam attach-role-policy --role-name $roleName --policy-name auth-access --policy-document file:///tmp/iam-role-policyDoc.json
aws ec2 associate-iam-instance-profile --iam-instance-profile $roleName --instance-id $instanceId

On the GCP side

Creating GCP resources

Bash

projectId="<GCP project ID>"
identityPool="aws-cloud-access"
providerId="aws-provider"
accountId="<AWS account ID>"
role="source-workload"

gcloud iam workload-identity-pools create $identityPool \
  --location="global" \
  --description="Allows resources in other clouds to access resources in GCP" \
  --display-name=$identityPool


gcloud iam workload-identity-pools providers create-aws $providerId \
  --location="global" \
  --workload-identity-pool=$identityPool \
  --account-id="$accountId" \
  --attribute-mapping="google.subject=assertion.arn,attribute.account=assertion.account,attribute.aws_role=assertion.arn.extract('assumed-role/{role}/'),attribute.aws_ec2_instance=assertion.arn.extract('assumed-role/{role_and_session}').extract('/{session}')" \
  --attribute-condition="assertion.arn.startsWith('arn:aws:sts::$accountId:assumed-role/')"

gcloud projects describe $(gcloud config get-value core/project) --format=value\(projectNumber\)

gcloud iam service-accounts add-iam-policy-binding $serviceAccountId \
  --role=roles/iam.workloadIdentityUser \
  --member="principal://iam.googleapis.com/projects/$projectId/locations/global/workloadIdentityPools/$identityPool/attribute.aws_role/$role"

gcloud iam workload-identity-pools create-cred-config \
    projects/$projectId/locations/global/workloadIdentityPools/$identityPool/providers/$providerId \
    --service-account=$serviceAccountEmail \
    --service-account-token-lifetime-seconds=3600 \
    --aws \
    --output-file=gcp_auth.json

On the source workload

Copy the gcp_auth.json file created previously over to the source workload.

gcloud login --cred-file=gcp_auth.json
gcloud storage describe gs://azure-cross-cloud-test-$projectNum

If the cross-cloud authentication worked, you should see details on the GCP storage bucket from your AWS instance without the need to store credentials that could leak and be used elsewhere.

Clean-up

gcloud storage buckets delete gs://azure-cross-cloud-test-$projectNum
gcloud iam service-accounts delete $serviceAccountEmail
gcloud iam workload-identity-pools delete $identityPool --location="global"

Accessing GCP resources from Azure

Google has provided a good amount of documentation on how to do this process. If you have a slightly different setup, you might want to have a look at some of their examples.

Configure workload identity federation with AWS or Azure

On the Azure side

You will need to configure the workload with a managed identity. You could use a system-assigned or user-assigned managed identity. If you use a user-assigned managed identity, make sure you store your managed identities in a separate protected resource group that most AD users do not have Contributor or higher access to. Anyone with access can generate tokens for the managed identity and impersonate the identity. This is why a system-assigned managed identity is preferred.

PowerShell

$resourceName = "<name of your existing resource>"
$resourceGroup = "<resource group name>"
$location = (Get-AzResourceGroup -Name $resourceGroup).Location

# If the Virtual Machine doesn't already have a managed identity, use the following to add one.
$vm = Get-AzVM -ResourceGroupName $resourceGroup -Name $resourceName
Update-AzVm -ResourceGroupName $resourceGroup -VM $vm -IdentityType SystemAssigned

# Get the application ID and object ID for the managed identity.
$vm = Get-AzVM -ResourceGroupName $resourceGroup -Name $resourceName
Get-AzADServicePrincipal -ObjectId $vm.Identity.PrincipalId

Write down the ApplicationId (client ID) and Id (object ID) returned as we will need that when granting access within AWS.

On the GCP side

You will need to enable the IAM Service Account Credentials API (iam.googleapis.com) from the GCP console before proceeding. How to enable an API

We are going to use gcloud CLI from a Linux command prompt for this example as that is the most used platform and method for accessing GCP from the command line. You can use the gcloud CLI command from Windows in a similar fashion.

Creating GCP resources

Bash

projectId="<GCP project ID>"
identityPool="azure-cloud-access"
providerId="azure-provider"
accountId="<AWS account ID>"
tenantId="<Azure tenant ID>"
clientId="<Managed identity client ID>"
objectId="<Managed identity object ID>"

serviceAccountName="azure-oidc-test"
serviceAccountEmail="${serviceAccountName}@${projectId}.iam.gserviceaccount.com"

gcloud iam workload-identity-pools create $identityPool --location="global" --description="Allows resources in other clouds to access resources in GCP" --display-name=$identityPool

gcloud iam workload-identity-pools providers create-oidc $providerId --location="global" --workload-identity-pool=$identityPool --issuer-uri="https://sts.windows.net/$tenantId" --allowed-audiences=$clientId --attribute-mapping="google.subject=assertion.sub,google.groups=assertion.groups"

projectNum=$(gcloud projects describe $projectId --format='value(projectNumber)')

gcloud iam service-accounts create $serviceAccountName \
  --description="Controlled by $clientId from Azure" \
  --display-name=$serviceAccountName

gcloud iam service-accounts add-iam-policy-binding $serviceAccountEmail \
  --role=roles/iam.workloadIdentityUser \
  --member="principal://iam.googleapis.com/projects/$projectNum/locations/global/workloadIdentityPools/$identityPool/subject/$objectId"

gcloud iam workload-identity-pools create-cred-config \
  projects/$projectNum/locations/global/workloadIdentityPools/$identityPool/providers/$providerId \
  --service-account=$serviceAccountEmail \
  --service-account-token-lifetime-seconds=3600 \
  --azure \
  --app-id-uri $clientId \
  --output-file=gcp_auth.json

# Create a temporary resource we can try accessing
gcloud storage buckets create gs://azure-cross-cloud-test-$projectNum --location=northamerica-northeast2 --pap --uniform-bucket-level-access
gcloud storage buckets add-iam-policy-binding gs://azure-cross-cloud-test-$projectNum --member=serviceAccount:$serviceAccountEmail --role=roles/storage.legacyBucketOwner

If the cross-cloud authentication worked, you should see details on the GCP storage bucket from your Azure VM without the need to store credentials that could leak and be used elsewhere.

On the source workload

Copy the gcp_auth.json file created previously over to the source workload.

gcloud login --cred-file=gcp_auth.json
gcloud storage describe gs://azure-cross-cloud-test-$projectNum

Clean-up

gcloud storage buckets delete gs://azure-cross-cloud-test-$projectNum
gcloud iam service-accounts delete $serviceAccountEmail
gcloud iam workload-identity-pools delete $identityPool --location="global"

Networking and security concerns

All of the above examples assume public IPs are attached to the workloads. If you have existing inbound/outbound network access controls in place, you will have to adjust them to allow access to the target cloud platform interfaces. You would also need to allow access from the source workload to any protected targets, be it API interface or resource.

With traditional secret based credentials, if they get compromised, they could be used from anywhere in the world. To prevent that, you would then need to use IP address whitelists. Using IP whitelists with public cloud providers is very problematic, bordering on impossible, as all potential IPs are not publicly available or are in a constant state of change.

Workload Identity Federation reduces the need for IP address whitelists for additional network security. This is because the authentication is locked down to the source identity and can’t be used outside of the constrains enforced by the source identity provider. If the identity is directly assigned to a workload, only that workload can use it, but if it is a shared identity, any resource allowed to use the identity can use it. You will need to make sure you are protecting the use of the identities and the resources they are granted to.

With Workload Identity Federation, instead of trusting shared credentials you are now trusting the application or workload. You should make sure the source application is well secured along with the operating system it lives on. Anything running on the source resource will have access to use the identity by default. You may be able to restrict access to the identity within the operating system.

Conclusion

Cross-cloud authentication was a major pain point with anyone that maintains multi-cloud environments. The ability to simplify and secure those integrations using Workload Identity Federation will take a load-off the management and securing of them. When implementing any future integrations, make sure you are using this method of authentication instead of the insecure and management intensive method of stored credentials and allowing IPs.

About James MacGowan

James started out as a web developer with an interest in hardware and open sourced software development. He made the switch to IT infrastructure and spent many years with server virtualization, networking, storage, and domain management.
After exhausting all challenges and learning opportunities provided by traditional IT infrastructure and a desire to fully utilize his developer background, he made the switch to cloud computing.
For the last 3 years he has been dedicated to automating and providing secure cloud solutions on AWS and Azure for our clients.

Cross-Cloud Authentication

Cross-Cloud Authentication

Workload Identity Federation

OpenID Connect

Granting identity to resources

Methods of attaching identity on each cloud

AWS - IAM Instance Profiles / IAM Roles

Azure - Managed Identity

GCP - Service Accounts

Examples

Accessing AWS resources from Azure

On the Azure side

On the AWS side

Create an IAM Identity Provider

Create an IAM role

On the source workload

Accessing AWS resources from GCP

On the GCP side

On the AWS side

Create an IAM Identity Provider

On the source workload

Accessing Azure resources from AWS

On the AWS side

Creating Cognito Identity Pool

Create IAM role

On the Azure side

Create User-Assigned Managed Identity

On the source workload

Accessing Azure resources from GCP

On the GCP side

On the Azure side

Create an Azure Managed Identity

On the source workload

Accessing GCP resources from AWS

On the AWS side

Create IAM role

On the GCP side

Creating GCP resources

On the source workload

Clean-up

Accessing GCP resources from Azure

On the Azure side

On the GCP side

Creating GCP resources

On the source workload

Clean-up

Networking and security concerns

Conclusion

About James MacGowan

Share This Article

Comments