Introduction: The Journey from Keys to Federation

In the early days of cloud authentication, service account keys were the go-to solution for applications and users needing access to Google Cloud resources. These keys were tangible—JSON files containing credentials that could be easily stored, managed, and shared. But with this simplicity came significant responsibility.

For security-conscious teams, storing these keys securely became paramount. Enter vault solutions. Organizations set up sophisticated vault systems to encrypt and manage these keys. Yet, this came with its own challenges. Setting up a vault involved intricate configurations, ensuring high availability, and managing permissions. Every interaction—whether an application fetching a key or a user accessing the vault—added layers of complexity and potential points of failure.

The process became a cycle: generate the key, store it in the vault, retrieve it securely, and use it to authenticate. For a simple task like accessing a cloud resource, the overhead was immense.

The Game Changer: Workload Identity Federation in GCP

Then came Workload Identity Federation in Google Cloud, a paradigm shift that replaced this cumbersome process with elegance and efficiency. With Workload Identity Federation, service account impersonation became the cornerstone of cloud authentication. Instead of relying on long-lived keys, applications could now authenticate using short-lived tokens derived from external identity providers.

The vault setup? No longer necessary. The risk of key compromise? Drastically reduced. By directly integrating with trusted identity providers like OIDC, organizations could securely authenticate workloads and users without ever touching a service account key.

This innovation not only simplified authentication but also improved security posture, making it easier for developers and administrators to focus on building and scaling applications without worrying about key management.

Understanding Workload Identity Pools

At the heart of Workload Identity Federation lies the Workload Identity Pool—a powerful construct that bridges external identities with Google Cloud. In essence, a workload identity pool allows you to manage external identities, enabling workloads running outside Google Cloud to authenticate seamlessly.

Before diving into the technical details, let’s simplify things with an analogy. Sometimes, abstract concepts like workload identity pools are easier to grasp when compared to everyday experiences. So, let’s think about how access works in a familiar setting—like a hotel.

Why This Approach Works

Just like hotels don’t rely on permanent keys—avoiding the risk of lost or stolen keys—workload identity pools eliminate the need for long-lived service account keys. This ensures secure, temporary access, making cloud resource management safer and more efficient.

Why Workload Identity Pools?

Consider a typical organization with multiple environments: development, staging, and production. Each environment may run on different platforms—Kubernetes clusters, on-premise servers, or even other cloud providers like AWS or Azure. Managing service account keys across these environments can quickly spiral into a logistical and security nightmare.

With workload identity pools, however, you can:

• Centralize Identity Management: Instead of juggling service account keys for each environment, you create a dedicated workload identity pool for each non-Google Cloud environment.
• Secure Access: External identities from identity providers (like AWS IAM, Azure AD, or custom OpenID Connect providers) authenticate through the pool, obtaining short-lived credentials without ever needing long-lived service account keys.
• Simplify Lifecycle Management: When an identity no longer requires access, revoking permissions is as simple as updating the pool’s configuration.

Best Practices: One Pool Per Environment

A key recommendation in designing your identity strategy is to create a separate workload identity pool for each environment. Here’s why:

1. Separation of Concerns: By isolating development, staging, and production, you reduce the risk of cross-environment leaks. If a compromise occurs in one pool, the blast radius is limited.
2. Environment-Specific Policies: Each pool can have tailored policies and configurations suited to the environment it serves. For example, your production pool might have stricter controls and auditing than your development pool.
3. Simplified Auditing and Monitoring: Tracking and auditing access is more straightforward when each environment’s identities are tied to distinct pools.

The Hotel Room Analogy

Imagine you’re staying at a hotel. When you arrive at the front desk, they don’t hand out permanent keys to guests. Instead, they verify your identity and check your reservation. Once everything is confirmed, they issue you a key card—a temporary pass that grants access to your specific room for the duration of your stay.

Here’s how this maps to Workload Identity Pools:

• The hotel is like your Google Cloud environment.
• The front desk represents the Workload Identity Pool. It’s responsible for verifying external identities (like AWS, Azure, or OIDC providers) and ensuring they’re allowed to access resources.
• Your reservation is the trust relationship between your external identity and the pool.
• The key card is the short-lived credential issued by the workload identity pool. This credential allows you to access Google Cloud resources temporarily.

When your stay is over, the key card stops working. Similarly, the credentials issued by workload identity pools are temporary, reducing the risk of misuse or exposure.

Workload Identity Providers: Connecting Your Identities to Google Cloud

While Workload Identity Pools serve as the gatekeepers for external identities, Workload Identity Providers define the actual pathways between Google Cloud and your external Identity Providers (IdPs). A workload identity provider describes the relationship between Google Cloud and the IdP, specifying how external identities can authenticate and obtain access.

Supported Identity Providers

Google Cloud supports a wide range of IdPs, allowing flexibility in integrating various environments and platforms. Here are some examples:

• AWS: Use IAM roles to authenticate workloads running on Amazon Web Services.
• Microsoft Entra ID (formerly Azure AD): Integrate with Microsoft’s enterprise identity service for user and application authentication.
• GitHub & GitLab: Authenticate CI/CD pipelines or other workflows running on these platforms.
• Kubernetes Clusters: Use identities from Kubernetes workloads (including GKE and self-managed clusters).
• Okta: Leverage Okta’s identity management platform for secure authentication.
• On-premises AD FS: Connect on-premises Active Directory Federation Services for hybrid cloud scenarios.
• Terraform: Authenticate workflows using Terraform Cloud’s identity.

How It Works: OAuth 2.0 Token Exchange

Workload Identity Federation is built on the OAuth 2.0 token exchange specification, ensuring a secure and standard process for obtaining credentials.

Here’s the flow:

1. Obtain a Credential from Your IdP: The workload (e.g., an application or service) authenticates with its external IdP, receiving a token or other credential as proof of identity.
2. Exchange the Credential: This credential is sent to Google Cloud’s Security Token Service (STS).
3. STS Verifies the Credential: The Security Token Service validates the token with the external IdP to ensure it’s legitimate and matches the expected identity.
4. Receive a Federated Token: Once verified, STS issues a federated token, which allows the workload to impersonate a Google Cloud service account and access the necessary resources.

Why This Matters

This system eliminates the need for long-lived credentials, such as service account keys, reducing security risks. It also simplifies the integration of external systems with Google Cloud, as workloads can use their existing identities and authentication mechanisms without requiring direct user intervention.

Let’s revisit our hotel analogy to better understand Workload Identity Providers.

In a hotel, the front desk (Workload Identity Pool) doesn’t just issue key cards to anyone. It needs to know who you areand where you’re coming from before granting access. This is where Workload Identity Providers come in—they act as the trusted verifiers for the hotel, confirming your identity before the front desk gives you access to your room.

Mapping the Analogy

• The front desk (Workload Identity Pool) manages who can request access and issues the temporary key card (short-lived credential).
• You (the external identity) present a form of identification when you check in.
• The trusted verifier (Workload Identity Provider) is your identity source—such as a passport, driver’s license, or employee badge. The front desk relies on these verifiers to confirm your identity.

In this scenario, the hotel might accept multiple forms of ID based on who you are and where you’re coming from:

• AWS: Like presenting a passport from another country, workloads running in AWS use IAM roles as their identity.
• Microsoft Entra ID: Similar to showing a corporate ID badge, Entra ID (Azure AD) confirms the identity of users and applications in a Microsoft ecosystem.
• GitHub/GitLab: Think of this as showing a conference badge to prove you’re part of a specific group or event.
• Kubernetes Clusters: Like presenting a local business ID if you’re coming from a nearby office.
• Okta/AD FS: Similar to corporate or government-issued credentials.
• Terraform: Think of this as bringing credentials issued by a trusted third-party contractor.

Once your identity is verified by the trusted verifier (Workload Identity Provider), the front desk issues your key card(federated token) to access your specific room (Google Cloud resources).

Behind the Scenes: Token Exchange

In technical terms, this process follows the OAuth 2.0 token exchange:

1. You present your credential (passport, badge, etc.) to the Security Token Service (STS), acting as the verifier.
2. STS checks with your trusted provider to validate your credential.
3. Once verified, STS issues a federated token (temporary key card), allowing you to access your “room” (Google Cloud resources).

Why It’s Important

By leveraging workload identity providers, the hotel (Google Cloud) can work with a variety of trusted verifiers, ensuring flexible and secure access for guests (workloads) coming from multiple sources. This eliminates the need for carrying permanent keys (long-lived credentials) and makes access more secure and manageable.

Demo: Setting Up Workload Identity Federation

In this demo, we’ll walk through the steps to set up Workload Identity Federation. This involves creating a service account with the required permissions and configuring a Workload Identity Pool to authenticate external workloads.

1. Create a Service Account

First, we’ll create a service account that external workloads will impersonate when accessing Google Cloud resources.

1. Navigate to the IAM & Admin > Service Accounts section in the Google Cloud Console.
2. Click Create Service Account and provide a name and description.
3. Assign the necessary roles for the resources the service account will access. For example:
   • Viewer: For read-only access to most resources.
   • Storage Admin: For managing Cloud Storage buckets.
   • BigQuery Admin: For managing BigQuery datasets.
4. Complete the setup and note the service account email for later steps.

2. Enable Workload Identity Federation and Create a Pool

Next, we’ll create a Workload Identity Pool to authenticate identities from external providers.

1. Go to IAM & Admin > Workload Identity Federation in the Google Cloud Console.
2. Click Create Pool and configure the following:
   • Name: Provide a unique name for the pool (e.g., external-id-pool).
   • Description: Add a description to indicate the purpose of the pool.
   • Location: Keep the default Global unless you require a regional pool.
3. Choose Access to Workload Identity Pool and select Active to enable the pool.

3. Add a Workload Identity Provider

A Workload Identity Pool needs a provider to verify external identities.

1. Under the pool you created, click Add Provider.
2. Select the Identity Provider Type based on your environment:
   • OIDC: For generic OpenID Connect-compatible IdPs.
   • AWS: To authenticate workloads running on AWS.
3. Configure the provider settings:
   • For OIDC:
     • Enter the Issuer URL of your OIDC provider.
     • Specify an Audience that matches your OIDC tokens.
   • For AWS:
     • Provide the AWS Account ID and configure IAM Role-to-Principal Mapping.
4. Save the provider configuration.

4. Bind the Service Account to the Workload Identity Pool

Finally, allow identities in the pool to impersonate the service account.

1. Open the IAM & Admin > IAM page in the Google Cloud Console.
2. Locate the service account you created earlier.
3. Click Edit Permissions and add the following role to the service account:
   • Workload Identity User: Grants identities in the pool permission to impersonate the service account.
4. Specify the pool as the Condition for this role binding.

Now that we have all the initial setup ready, Lets see the workflow in action. I had already explained about the Github action in my previous blog post

Conclusion:

Workload Identity Federation in GCP represents a transformative step forward in cloud authentication, replacing long-lived keys with secure, temporary tokens derived from trusted identity providers. By integrating this feature into your workflows, you not only enhance security but also streamline access management across diverse environments.

From eliminating the overhead of key management to enabling seamless authentication for platforms like GitHub, Workload Identity Federation empowers organizations to focus on innovation rather than infrastructure.

Whether you’re scaling your CI/CD pipelines, connecting external workloads, or ensuring compliance, this approach aligns with modern best practices for cloud-native security.

By adopting Workload Identity Federation, you’re future-proofing your cloud strategy—embracing a model that prioritizes security, simplicity, and scalability.