workload-identity-federation

Configuring workload identity federation to access Google Cloud resources from apps running on Azure

The most straightforward way for workloads running outside of Google Cloud to call Google Cloud APIs is by using a downloaded service account key. However, this approach has 2 major pain points:

• A management hassle, keys need to be stored securely and rotated often.
• A security risk, keys are long term credentials that could be compromised.

Workload identity federation enables applications running outside of Google Cloud to replace long-lived service account keys with short-lived access tokens. This is achieved by configuring Google Cloud to trust an external identity provider, so applications can use the credentials issued by the external identity provider to impersonate a service account.

This blueprint shows how to set up everything, both in Azure and Google Cloud, so a workload in Azure can access Google Cloud resources without a service account key. This will be possible by configuring workload identity federation to trust access tokens generated for a specific application in an Azure Active Directory (AAD) tenant.

The following diagram illustrates how the VM will get a short-lived access token and use it to access a resource:

The provided terraform configuration will set up the following architecture:

• On Azure:

  • An Azure Active Directory application and a service principal. By default, the new application grants all users in the Azure AD tenant permission to obtain access tokens. So an app role assignment will be required to restrict which identities can obtain access tokens for the application.

  • Optionally, all the resources required to have a VM configured to run with a system-assigned managed identity and accessible via SSH on a public IP using public key authentication, so we can log in to the machine and run the gcloud command to verify that everything works as expected.

• On Google Cloud:

  • A Google Cloud project with:

    • A workload identity pool and provider configured to trust the AAD application

    • A service account with the Viewer role granted on the project. The external identities in the workload identity pool would be assigned the Workload Identity User role on that service account.

Running the blueprint

Clone this repository or open it in cloud shell, then go through the following steps to create resources:

• terraform init
• terraform apply -var project_id=my-project-id

Testing the blueprint

Once the resources have been created, do the following to verify that everything works as expected:

1. Log in to the VM.

   If you have created the VM using this terraform configuration proceed the following way:

   • Copy the public IP address of the Azure VM and the username required to log in to the VM via SSH from the output.

   • Save the private key to a file

     terraform state pull | jq -r '.outputs.tls_private_key.value' > private_key.pem

   • Change the permissions on the private key file to 600

     chmod 600 private_key.pem

   • Login to the Azure VM using the following command:

     ssh -i private_key.pem azureuser@VM_PUBLIC_IP

   If you already had an existing VM with the gcloud CLI installed that you want to use, you will have assign its managed identity an application role as explained here.

2. Create a file called credential.json in the VM with the contents of the credential output.

3. Authorize gcloud to access Google Cloud with the credentials file created in the step before.

   `gcloud auth login --cred-file credential.json

4. Get the Google Cloud project details

   gcloud projects describe PROJECT_ID

Once done testing, you can clean up resources by running terraform destroy.

Variables

name	description	type	required	default
project_id	Identifier of the project that will contain the Pub/Sub topic that will be created from Azure and the service account that will be impersonated.	string	✓
project_create	Parameters for the creation of the new project.	object({…})		null
vm_test	Flag indicating whether the infrastructure required to test that everything works should be created in Azure.	bool		false

Outputs

name	description	sensitive
credential	Credential configuration file contents.
tls_private_key	Private key required to log in to the Azure VM via SSH.	✓
username	Username required to log in to the Azure VM via SSH.
vm_public_ip_address	Azure VM public IP address.