You just deployed a stateless service on Cloud Run, but it needs to pull data from an S3 bucket that lives in AWS. Two clouds, two identity systems, one developer quietly regretting everything. There’s a cleaner path than juggling long‑lived keys or custom proxies.
Cloud Run runs stateless containers in Google Cloud, scaling from zero on demand. Amazon S3 stores data in objects with fine‑grained access policies. Connecting them securely means giving Cloud Run just‑in‑time credentials to access S3 through temporary tokens, not permanent secrets. Once you do that, Cloud Run S3 integration stops being a headache and starts behaving like a single system.
The trick is identity. Cloud Run uses Google service accounts based on OpenID Connect (OIDC). AWS IAM can trust external OIDC providers. You set up a trust so AWS recognizes your Cloud Run service as a valid identity source. When a container sends a signed OIDC token on each request, AWS issues short‑term access rights to that specific workload. No keys baked into images. No secret rotation scripts. Just dynamic trust between clouds.
Quick answer: Cloud Run S3 integration uses OIDC federation. Google’s identity token authenticates your running service to AWS IAM, which then provides temporary credentials for S3 access. It removes the need for static keys and keeps cross‑cloud access auditable and secure.
A few best practices make it stick:
- Scope permissions narrowly in AWS IAM policies. Grant only the bucket or prefixes your service needs.
- Use audience matching in OIDC trust configs to ensure the right Cloud Run service is calling.
- Cache credentials briefly in memory, never persist them to disk.
- Rotate or revoke OIDC trust if you decommission a service.
Benefits developers actually see:
- No hard‑coded AWS keys in environment variables.
- Automatic credential rotation by design.
- Observable audit trails across both IAM systems.
- Faster deploys since security auditors stop blocking key distribution.
- Reduced on‑call noise from expired tokens or leaked secrets.
The developer experience improves overnight. Onboarding new services becomes copy‑paste simple. Instead of waiting days for Ops to hand out credentials, you deploy, the service identifies itself, and access works. Developer velocity goes up because authentication becomes infrastructure, not ceremony.
Platforms like hoop.dev turn those access rules into guardrails that enforce policy automatically. It checks identity at the proxy layer and keeps the same rule logic consistent across multi‑cloud APIs. You write the policy once, and every endpoint follows it without extra YAML acrobatics.
AI copilots add another angle here. When they generate code that touches storage, consistent identity between Cloud Run and S3 prevents your assistant from suggesting insecure token usage. Automated agents get temporary access just like humans, which keeps compliance teams calmer and logs cleaner.
This setup rewires the traditional trust model. Instead of secrets chasing environments, services prove who they are in real time, and AWS hands them just enough access to finish the job.
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.