Implementing Secure Workload Identity for Google Cloud Run

Introduction

Cloud-native services often rely on service account keys for authentication, a practice that introduces significant security overhead and lifecycle management burdens.

When static keys are generated, downloaded, and embedded within service environments, they persist indefinitely until an administrator manually revokes them. Workload Identity For Google Cloud Run persistence creates a massive identity blast radius if a file is accidentally committed to a repository or exposed via an insecure logging endpoint.

Implementing Workload Identity for Google Cloud Run services replaces these long-lived static credentials with ephemeral tokens issued by the platform. Workload Identity For Google Cloud Run approach enforces zero-trust principles by ensuring that identities are tied directly to the runtime environment rather than external secrets.

By leveraging IAM-based identity propagation, organizations minimize their reliance on manual credential rotation and drastically lower the risk of unauthorized access due to leaked keys.

Prerequisites

Successful implementation of Workload Identity requires specific Google Cloud IAM permissions and configured command-line tools. Admin` for deploying Cloud Run services.

You should install the latest gcloud SDK to ensure you have access to the most recent command flags, specifically those related to service account association.

Ensure that your organization policy does not restrict the creation of new service accounts or the modification of Cloud Run identity settings, as these constraints often result in failed deployments during the cutover phase.

Before attempting migration, document the existing service account usage patterns across your tenant to confirm which workloads currently rely on static keys. You must verify that your environment has the necessary project-level permissions to bind IAM roles to the specific service account you intend to use for your application runtime.

If you are operating in a multi-project setup, confirm that the Cloud Run service project has the necessary cross-project service account access permissions configured.

Step-by-step implementation

The following procedure establishes a secure identity foundation for your Cloud Run environment by migrating from manual key management to ephemeral identity binding. Execute these steps carefully in your development or staging environment before propagating changes to production services to ensure no service disruption occurs.

Step 1: Audit existing service account configurations

Begin the migration process by conducting a thorough audit of your active Google Cloud Run services to identify any workloads currently depending on static JSON keys.

Use the Google Cloud admin console to view the service details for your running containers and check the 'Security' or 'Identity' tabs for existing secret mounts or environment variable references.

You must also scan your application code and CI/CD pipelines to locate instances where service account key files are being injected into the container at runtime.

If a service is already using the default Compute Engine service account, note its permissions, as this default identity is often over-privileged and rarely adheres to the principle of least privilege (see least privilege).

Document the findings for every service in a tracking sheet to create a rollback plan, ensuring you can revert to the previous configuration if the identity switch causes authentication failures.

Verify if any external systems or legacy services strictly require.

Step 2: Create a dedicated, least-privileged service account

Create a new service account specifically for your Cloud Run service to enforce granular access controls. Avoid reusing the default Compute Engine service account, as it typically possesses excessive permissions that widen the potential blast radius.

Use the gcloud command line to define the identity with minimal necessary access: gcloud IAM service-accounts create [SA NAME] --display-name='Service identity for [SERVICE NAME]'. ObjectViewer` in the control plane.

Only grant the permissions that are strictly required for the service to function, and avoid broad editor or owner roles. This configuration ensures that if the service is compromised, the attacker is limited to the specific subset of resources the service account can touch.

Keep a record of the service account email address, as you will use this identifier in the subsequent binding and deployment steps.

Step 3: Bind IAM roles to the workload identity

Assign the necessary IAM policies to your newly created service account to enable interaction with the required backend resources. Execute the following command for each required permission: gcloud projects add-IAM-policy-binding [PROJECT ID] --member='serviceAccount:[SA EMAIL]' --role='[ROLE NAME]'.

By explicitly binding roles to the service account, you move away from global settings and create a tight coupling between the identity and the resources it needs to manage. For cloud-to-cloud integrations, review the specific identity requirements documented in key management (see Key Management).

Ensure that your policy bindings are committed to your infrastructure-as-code repository to maintain an auditable trail of access changes. If your Cloud Run service requires access to resources in different projects, verify that the cross-project IAM bindings are correctly propagated.

Validate the binding state by running gcloud projects get-IAM-policy [PROJECT ID] to confirm.

Step 4: Update Cloud Run service deployment configuration

Apply the new service account to your Cloud Run deployment to force the environment to use the platform-provided identity. Update your service configuration using the gcloud command: gcloud run services update [SERVICE NAME] --service-account=[SA EMAIL].

This command instructs the Cloud Run runtime to provision ephemeral tokens that your application code can retrieve automatically from the Google Cloud metadata server.

During this update, ensure that the deployment strategy supports a gradual rollout if you are using traffic splitting, allowing you to observe the new identity behavior without immediately impacting all production traffic.

Modify your environment variables to ensure the SDK correctly detects the environment-provided identity.

Check that your deployment pipeline does not overwrite this setting by injecting old static keys during the build or deploy phase, which would negate the security benefits of the transition.

Step 5: Revoke static credentials and verify identity propagation

Once the service successfully authenticates using the new ephemeral identity, revoke the old static keys to finalize the migration and eliminate the risk of credential leakage. Use the command gcloud IAM service-accounts keys delete [KEY ID] --IAM-account=[SA EMAIL] to permanently remove the static credentials from your project.

Before deletion, perform a final status check in the Cloud Audit Logs to confirm the service is consistently using the new identity, not falling back to legacy keys.

If you notice a spike in '403 Forbidden' errors, a failure mode identified in common security telemetry analysis, immediately halt the deletion process and verify the IAM binding in Step 3. This rollback strategy, combined with careful audit monitoring, ensures that your service remains available while removing technical debt.

Once the keys are revoked, update your secrets management documentation to reflect that the service no longer requires external file-based credentials, significantly reducing your compliance burden.

Validation and testing

Validation of your Workload Identity implementation requires verifying that the Cloud Run service correctly fetches and uses its assigned identity via the metadata server. Begin by inspecting the metadata server endpoint within your container to confirm that it returns the expected service account email and token data.

Access the URL from within your container logs or via an ephemeral shell if troubleshooting a failure. Additionally, query the Cloud Audit Logs for 'data access' events; these logs will show the identity used.

Common pitfalls

Implementation failures often stem from misconfigured permissions or stale environmental variables that disrupt the identity flow. A frequent mistake is failing to account for propagation delays, where IAM role changes take several minutes to reflect across the Google Cloud global fabric.

If you find your service receiving '403' errors immediately after deployment, wait five minutes and retry the request before assuming a misconfiguration. Another common pitfall is the 'audience mismatch,' where the service account lacks the necessary scopes to access a specific API service, even if the role appears correctly bound.

Avoid using overly permissive roles like 'Editor' during the debugging phase; instead, use the principle of least privilege and grant only the specific IAM roles required.

Finally, ensure that your application-side SDKs are configured to use the default credential provider, as hardcoded file paths often force the SDK to bypass the metadata server entirely. Documenting these specific failure modes in your internal runbooks helps incident responders identify issues faster if service disruption occurs post-cutover.

Related topics and next reads

FAQ

What is the difference between static service account keys and Workload Identity?

Static service account keys are long-lived, file-based credentials that must be manually rotated and secured. If leaked, they pose a persistent security risk. Workload Identity uses ephemeral, platform-managed tokens that expire automatically, significantly reducing the impact of potential exposure and eliminating manual rotation overhead.

How do I verify that my Cloud Run service is using the correct identity?

Check the Cloud Audit Logs for 'data access' entries, which will explicitly list the service account used for the API call. You can also query the Google metadata server from within your running container at to confirm the currently active identity.

Can I use Workload Identity for cross-project access in GCP?

Yes. You must grant the Cloud Run service account IAM roles on the target project's resources. Workload Identity functions across project boundaries as long as the appropriate cross-project IAM policy bindings are configured correctly.

Why should I rotate service account keys if I'm not using Workload Identity?

If you are not using Workload Identity, you must rotate static keys to limit the window of opportunity for an attacker if a key is compromised. Frequent rotation is a critical defense-in-depth measure, though it is significantly less effective and more operationally intensive than the ephemeral tokens provided by Workload Identity.

What permissions are required to associate a service account with a Cloud Run service?

ActAs` permission on the target service account to successfully associate it with a service.