How to configure AWS Secrets Manager Cloud Run for secure, repeatable access

You have a service on Cloud Run that needs to talk to AWS. Maybe it needs a database password, an API key, or something more exotic. Hard-coding it is career malpractice. Copy-pasting secrets into CI pipelines is gray-hat chaos. The right move is to let AWS Secrets Manager hold your crown jewels and let Cloud Run fetch them at runtime, safely and automatically.

AWS Secrets Manager is AWS’s managed vault for credentials, tokens, and configuration data. It rotates values, encrypts them with KMS, and logs every retrieval through CloudTrail. Google Cloud Run, on the other side, runs containers without servers and scales transparently. When these two meet, you get a clean workflow: stateless containers calling AWS APIs securely, no manual exports or environment-variable roulette needed.

The integration logic is simple. Cloud Run acts as a client and requests the secret via AWS’s SDK. That request must carry valid AWS credentials, which you can authorize through a short-lived token or an AWS Identity and Access Management (IAM) role tied to an external identity. OIDC federation is the modern trick here. Cloud Run’s service identity signs an OIDC token, AWS validates it, and if your IAM trust policy allows it, the request to Secrets Manager succeeds. No static keys ever leave AWS.

When something breaks, it’s almost always IAM. Check your trust relationships between the Google identity provider and AWS IAM. Rotate access tokens regularly, and confirm your Secrets Manager policy allows the GetSecretValue action for that assumed role. If you log retrieval calls, you can spot failing requests before they snowball into outages.

Quick Answer:
To connect Cloud Run to AWS Secrets Manager, enable OIDC federation between Google and AWS, assign an IAM role with access to your secret, and have your Cloud Run container request that secret using AWS’s SDK. This avoids any hard-coded credentials.

Benefits of this setup

• Zero leaked secrets in Git or CI.
• Automatic secret rotation through AWS APIs.
• Strong auditing through CloudTrail logs.
• Consistent identity from dev to prod.
• No extra infrastructure. No cron jobs.

Platforms like hoop.dev turn those access rules into guardrails that enforce policy automatically. Instead of developers juggling tokens and IAM JSON blobs, hoop.dev can connect your ID provider, check requests in real-time, and apply conditions so every Cloud Run call to AWS Secrets Manager stays inside compliance lines.

For developers, this setup saves hours of debugging failed auth. Identity becomes one source of truth. Onboarding gets faster, and nobody needs to file a ticket to get secrets for staging. Velocity increases not because of magic but because policy stops getting in your way.

AI-powered agents add another dimension. As LLM-based tools begin automating infrastructure changes, they might trigger operations that need secrets access. With AWS Secrets Manager Cloud Run integration and identity-aware audit trails, you can let automation work without exposing sensitive data to prompts or logs.

Done right, the secret fetch becomes an invisible detail instead of a recurring nightmare. Identity evaluates, AWS verifies, and Cloud Run runs.

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.