The simplest way to make Cloud Run SAML work like it should

You finish deploying a shiny new service to Cloud Run. It’s running beautifully until your security team asks how SSO fits into the picture. Suddenly, you are knee-deep in identity acronyms and wondering how SAML handshakes fit inside a stateless container world.

Cloud Run handles your compute with excellent isolation. SAML handles identity with excellent formality. The trick is getting them to talk. You want a browser login to turn into a valid session your Cloud Run service understands without custom glue logic or brittle token exchanges.

Both systems live at opposite ends of the stack. Cloud Run speaks HTTP, containers, and service accounts. SAML speaks XML assertions, identity providers, and trust signatures. The bridge is the identity-aware proxy pattern. It verifies users upstream and forwards verified tokens downstream, giving Cloud Run a way to know who’s calling without storing state. When configured correctly, this setup gives you enterprise-grade access control with the simplicity of serverless.

Here’s the basic flow. A user hits your public HTTPS endpoint. The proxy intercepts the request and redirects them to your chosen SAML IdP, maybe Okta or Azure AD. The IdP validates credentials, issues a SAML response, and returns control to the proxy. The proxy checks signatures, extracts basic claims, and injects identity headers before forwarding traffic to Cloud Run. The service only sees pre-authenticated requests and can rely on upstream verification.

A quick answer for people who search “How do I connect Cloud Run and SAML?”: you do not configure SAML inside Cloud Run itself. You front Cloud Run with an identity-aware proxy that handles the SAML authentication, then pass verified headers to your app. The proxy owns user identity, and Cloud Run remains stateless, scalable, and simple.

To keep it tidy:

• Use short session TTLs and refresh SAML assertions often.
• Map SAML roles to service-level permissions through IAM bindings.
• Validate the IdP signature chain every time, not just at startup.
• Log user claims for auditing but redact PII before long-term storage.

Engineers like this pattern because it is fast and repeatable. No manual credential copying. No surprise access holes when containers rotate. Once your proxy is in place, onboarding and offboarding users becomes an identity-side task, not a deployment problem. Developer velocity improves and approval churn drops. Everyone moves faster with fewer Slack messages about “who can access staging.”

Platforms like hoop.dev turn those access rules into guardrails that enforce policy automatically. Instead of building a proxy from scratch, you define intent-based access paths, connect your identity provider, and let the system handle request verification everywhere Cloud Run runs. The combination respects enterprise compliance frameworks like SOC 2 while keeping logs clean and verifiable.

AI assistants can even help analyze proxy logs now, highlighting failed SAML assertions or expired credentials. That insight closes the loop, preventing silent authentication drift as configurations change.

In the end, Cloud Run and SAML fit together cleanly when trust is handled upstream. You get serverless scale, enterprise identity, and peace of mind.

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.