Eliminating Google Cloud Service Account Keys Using Workload Identity Federation

Why This Still Breaks in Enterprises

Static service account keys are one of the last remaining hard-coded secrets in enterprise cloud environments. They are expensive to manage, painful to rotate, and fundamentally incompatible with modern security models. Many modern SaaS platforms now support Workload Identity Federation out of the box. However, large enterprises rarely operate exclusively in SaaS-only or cloud-native environments. There is often a long tail of internal workloads:

• Batch jobs
• Data synchronization pipelines
• Operational scripts using gcloud
• Legacy services running outside Google Cloud
• Accessing GCP resources from on-premises or hybrid cloud environments

⚠️ Even when organizations adopt WIF at the platform level, legacy pipelines remain an exception — and exceptions are where static credentials survive the longest.

This article describes a proven enterprise pattern for eliminating long-lived Google Cloud service account keys using Workload Identity Federation and executable-sourced credentials. Authentication is externalized, and Google Cloud handles token exchange, impersonation, and lifecycle management.

Identity-First Access: Workload Identity Federation in Practice

This architectural pattern and its practical implementation demonstrate how systems eliminate long-lived credentials by exchanging enterprise identity for Google Cloud access at runtime.

💡 No application code changes are required. Applications continue to use the same Google Cloud Auth libraries, while authentication becomes a platform-managed capability.

Execution Flow

1. Application or job starts
2. Google Cloud Auth library invokes the configured executable
3. Executable library authenticates with CyberArk or Vault
4. Enterprise IdP issues a short-lived OIDC token
5. Executable library outputs the token
6. Google Cloud library exchanges the token via WIF
7. Application or job receives a short-lived Google access token

Design Principles

Several design principles make this pattern scalable and safe:

1. Single responsibility The executable does one thing: produce a valid external identity token.
2. No embedded secrets The library relies on environment-level or host-level authentication to access enterprise systems.
3. Language-agnostic interface Any language capable of invoking an executable can use this pattern.
4. Central distribution The executable is published to an internal artifact repository and versioned like any other platform dependency.

✅ This allows security teams to review and harden authentication logic once, instead of auditing hundreds of applications.

Supporting Multiple Languages

• identical command-line arguments
• identical output format
• consistent logging and error semantics

💡 Standardizing the interface matters more than standardizing the implementation language.

End to End Workload Identity Federation Execution Flow

The following diagram illustrates how this pattern works in practice:

Prerequisites

Before implementing this pattern, a one-time configuration is required to establish mutual trust between Google Cloud and your Enterprise Identity Provider (IdP). This setup follows standard OIDC federation principles:

✅ Once the provider is created, Google Cloud can cryptographically verify OIDC tokens signed by your IdP without requiring any static secrets or long-lived keys.

Phase 1: External Identity, Not Google Keys

The application never starts with a Google credential. It starts with its own identity, issued by an enterprise IdP. Steps 3 to 5 in the diagram.

Zero Trust Enforcement Inside the Library

One of the key success factors in this approach was enforcing Zero Trust principles directly inside the reusable authentication library, rather than relying solely on external controls. In practice, the library did not blindly fetch credentials. Instead, it applied explicit trust validation and policy checks before requesting or emitting any identity token.

💡 This ensured that possession of execution access alone was not sufficient to obtain credentials.

What Zero Trust Meant in Practice

Inside the library, Zero Trust was implemented by validating multiple signals before proceeding:

• Execution context validation
The library verified that it was running in an expected environment (for example, specific hosts, namespaces, or workload identifiers).
• Caller intent and scope checks
Requests for credentials were evaluated against allowed scopes, environments, and target service accounts.
• Explicit trust boundaries
The library enforced which IdP, workload identity pool, and provider combinations were permitted — preventing misuse across environments.
• Short-lived, least-privilege tokens
Tokens were always scoped, ephemeral, and tied to a single execution context.

⚠️ Without these checks, the executable becomes just another credential-fetching utility — which defeats the purpose of Zero Trust.

The Reusable Authentication Library Pattern

The core of this approach is a reusable authentication executable that acts as a bridge between enterprise identity systems and Google Cloud’s Workload Identity Federation. Rather than embedding authentication logic in every application, the enterprise implements a single, well-defined library whose only responsibility is to obtain a valid external identity token and present it in a format understood by Google Cloud’s authentication libraries.

💡 This shifts authentication from an application concern to a centrally governed platform capability.

Core Responsibilities of the Library

At a high level, the library is responsible for three things:

1. Securely accessing enterprise credential systems The library authenticates with enterprise-managed systems such as CyberArk or HashiCorp Vault to retrieve the minimum credentials required to interact with the corporate Identity Provider (IdP).
2. Minting or retrieving an OIDC token from the IdP Using the retrieved credentials, the library requests an OIDC-compliant identity token from the enterprise IdP. This token represents the workload’s identity, not a static secret.
3. Emitting credentials in a Google-compatible format The token is written to STDOUT (or an output file) in the exact format expected by Google Cloud’s Auth libraries. From this point forward, Google Cloud handles token exchange, service account impersonation, and refresh.

The library emits a JSON object to STDOUT (or a specified file) containing the OIDC token and metadata. This is the exact format expected by Google Cloud’s authentication libraries. Here is the sample output:

{
    "version":1,
    "success":true,
    "token_type":"urn:ietf:params:oauth:token-type:id_token",
    "id_token":"eyJraWQiOiJHb29nbGVXb3Jr...<OIDC_TOKEN>...",
    "expiration_time" :1770657620
}

Here is the sample executable-sourced.json that is used by the library to obtain the OIDC token:

{
    "universe_domain": "googleapis.com",
    "type": "external_account",
    "audience": "//iam.googleapis.com/projects/<gcp-numeric-id>/locations/global/workloadIdentityPools/<pool-id>/providers/<provider-id>",
    "subject_token_type": "urn:ietf:params:oauth:token-type:jwt",
    "token_url": "https://sts.googleapis.com/v1/token",
    "credential_source": {
        "executable": {
            "command": "-cp <path-to-jar/library> com.garvik.wif.GetOIDCToken",
            "timeout_millis": 30000
        }
    },
    "service_account_impersonation_url": "https://iamcredentials.googleapis.com/v1/projects/-/serviceAccounts/<service-account-email>:generateAccessToken",
    "service_account_impersonation": {
        "token_lifetime_seconds": 3600
    }
}

Phase 2: Token Exchange, Not Trust

Trust is never assumed — it is continuously verified. The application exchanges its enterprise token for a short-lived Google access token. Steps 4 to 5 in the diagram, lets break down the process.

The application/process uses the OIDC token obtained from the zero trust library to request a Google access token. This exchange is performed using the Google Cloud Client Library, which handles the token exchange process. The Google Cloud Client Library forwards the IdP token received in (5) to GCP’s Security Token Service (STS) (6). The Security Token Service (STS) evaluates the token (7-2) to verify the audience of the external identity token and the token issuer. The external identity token is signed with the external IdP’s private key. The corresponding public keys that are used in the validation process are accessible as each OIDC provider publishes the URI for accessing these keys (jwks_uri) in the /.well-known/openid-configuration document . With these public keys the STS verifies the token signature (7-1). STS returns a short lived (1 hr) federated GCP token (8).This step completes the federated identity exchange process.

Phase 3: Impersonation, Not Delegation

The application/process never uses its own identity to access Google Cloud. It impersonates a Google service account, which has the precise permissions required for the task. Steps 6 to 10 in the diagram.

The application/process uses the short-lived federated GCP token (8) to impersonate a Google service account present in the properties file service_account_impersonation_url. The federated GCP token is exchanged for a short-lived access token for the service account at step 9 & 10. With this access token, the application can access the Google Cloud resources that the service account has been granted access to.

Short-Lived Credentials, Not Long-Lived Secrets

Google access tokens are short-lived (1 hour by default and you can configure it to be different by customizing the property value SERVICE_ACCOUNT_TOKEN_LIFETIME). They are automatically refreshed, eliminating the need for manual rotation or key management.

Executable vs URL Approach

Google library offers 3 ways how one can feed the federated identity token. executable-sourced-credentials, file-sourced-credentials, and url-sourced-credentials.

executable-sourced-credentials: This approach uses an executable to fetch the federated identity token.

file-sourced-credentials: This approach uses a file to fetch the federated identity token.

url-sourced-credentials: This approach uses a URL to fetch the federated identity token.

This table will compare the 2 approaches and help you choose the best approach for your use case. the file-sourced-credentials approach is not compared as it is not recommended for production use cases as it requires you to store the federated identity token in a file, which is a security risk.

The URL-sourced credential mechanism does not dictate the method of identity verification; it merely designates the http endpoint from which the Google Auth library will retrieve a token. Consequently, the responsibility of proving identity rests entirely with your implementation. This is a primary reason why executable-sourced credentials are often preferred for enterprise scenarios. They offer greater flexibility and control, allowing you to:

• Generate tokens using custom logic tailored to your requirements.
• Perform local token validation.
• Maintain strict control over token signing.

How Cloud Metadata Servers Work (The "URL Pattern")

Cloud metadata servers (whether Google Cloud, AWS, or Azure) use a fixed, local URL pattern.

• Google Cloud: http://metadata.google.internal/ or http://169.254.169.254/
• AWS: http://169.254.169.254/latest/meta-data/
• Azure: http://169.254.169.254/metadata/instance

Why it is considered Secure

These are link-local addresses. They are considered highly secure because:

• Hypervisor Interception: Traffic to 169.254.169.254 never actually hits a physical network, the public internet, or even your VPC. The hypervisor running the physical host machine intercepts that IP address.
• Strict Isolation: Only the specific Virtual Machine (or container) making the request can see its own metadata. VM "A" cannot query VM "B's" metadata, even if they are right next to each other.
• SSRF Protection: To prevent Server-Side Request Forgery (where a hacker tricks your app into fetching the URL on their behalf), these servers require mandatory HTTP headers to prove the request is intentional. (e.g., Google requires Metadata-Flavor: Google; Azure requires Metadata: true).

Conclusion

Executable-sourced credentials provide a pragmatic, low-friction path for enterprises to eradicate static service account keys—especially in legacy or operational workflows that cannot be easily rewritten. Combined with Workload Identity Federation, they enable a true Zero-Trust model: identity-based, short-lived, auditable, and centrally governed.

This is not just a security improvement—it is a structural upgrade to how enterprises authenticate in the cloud.

Resources

For more information about Workload Identity Federation, see the following resources:

• Workload Identity Federation Documentation
• Setup Workload Identity Federation
• Workload Identity Federation with AWS
• Workload Identity Federation with Azure