Cross-Cloud Authentication

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.


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.

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.


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.

Share This Article