Your service starts smoothly. Then it needs credentials. Suddenly, half your runtime budget disappears in secret management firefighting. Cloud Run HashiCorp Vault integration fixes that, letting your app fetch credentials securely without shipping environment variables that end up printed in logs six months later.
Cloud Run brings managed container execution with identity baked into the platform. HashiCorp Vault provides identity-aware secrets storage, policy enforcement, and audit trails you can show to your compliance team without shame. Together, they form a clean chain of trust between service, token, and secret.
The integration works like this: Cloud Run generates a short-lived identity token tied to each deployed instance. That token can be exchanged for Vault credentials using Google IAM’s OIDC federation. Vault’s policies define which paths each workload can access, and Cloud Run’s service account ensures each job runs under a predictable identity. The result is controlled, ephemeral authorization without any hard-coded secrets or manual rotation scripts.
To make it practical, define one Vault role for each Cloud Run service account. Enable the JWT/OIDC auth method in Vault, map the issuer to Google’s token endpoint, and set policies that match what the service should read or write. This pattern avoids long-lived tokens and scales elegantly if you deploy dozens of microservices. Debugging misconfigurations is faster too because identity mismatches show up immediately in Vault’s audit log.
Follow these best practices for smooth operation:
- Tie Vault roles to Cloud Run service accounts, not to human users.
- Rotate tokens automatically using Vault’s leasing system.
- Use fine-grained policies instead of wide “read everything” permissions.
- Validate that your Cloud Run identity provider matches Vault’s expected audience claim.
- Log every access and review it before your SOC 2 audit, not during it.
Benefits are clear:
- Secrets never touch disk or source control.
- Access is ephemeral and verifiable.
- Compliance mapping gets simpler across Okta, AWS IAM, and OIDC stacks.
- Fewer midnight redeploys after credentials expire.
- Developers spend less time chasing permission errors and more time writing code.
With this setup, developer velocity jumps. No one waits on security tickets just to test staging. Vault becomes an invisible gatekeeper instead of a stubborn lock. Platforms like hoop.dev turn those access rules into guardrails that enforce policy automatically, verifying every call before it hits your endpoint.
How do you connect Cloud Run Identity to Vault directly?
Use OIDC tokens issued by Cloud Run’s metadata server. Configure Vault’s JWT auth method to trust Google’s issuer and map claims to Vault roles. Once done, your service can request secrets securely without any stored credentials at all.
As AI-powered automation enters CI/CD pipelines, this foundation matters more. Agents and copilots that trigger workflows need scoped, auditable access too. Vault’s identity model lets them interact with Cloud Run resources safely so machine-driven tasks follow the same least-privilege rules as humans.
When you see your workloads scaling without a flood of leaked keys, you know it is working. Build once, ship anywhere, and trust your pipeline from token to storage.
See an Environment Agnostic Identity-Aware Proxy in action with hoop.dev. Deploy it, connect your identity provider, and watch it protect your endpoints everywhere—live in minutes.