The simplest way to make Azure App Service Cloud Run work like it should

You push code, hit deploy, and hope. Somewhere between Azure App Service and Cloud Run, requests vanish or timeouts multiply. The promise of “serverless everything” starts to look more like “serverless confusion.” Let’s fix that.

Azure App Service excels at running web applications under Microsoft’s managed platform with tight Azure AD integration. Google Cloud Run, on the other hand, packages workloads into containers that scale down to zero. Many engineering teams use both. Maybe your main app lives on Azure but you rely on Cloud Run for event-driven jobs, AI microservices, or image processing. Connecting them cleanly is where things get interesting.

The key is identity and networking. Azure App Service Cloud Run integration happens when your App Service authenticates through OpenID Connect (OIDC) or a federated service account so it can invoke Cloud Run endpoints securely. Instead of hardcoding secrets, you map Azure Managed Identities to Cloud Run’s IAM roles using OIDC tokens. The exchange is short-lived, verified, and logged, so no keys drift around your repo. Requests stay inside TLS boundaries, and both clouds trust the same cryptographic proof of identity.

To make it work, set Azure App Service to request an OIDC token audience that matches your Cloud Run service URL. In Cloud Run, grant the corresponding service account run.invoker permission. Test it once, log everything, and watch your cross-cloud calls flow in under a second.

If your logs still complain about permissions, check the token audience claim. That tiny mismatch is the number-one cause of 403s. Also, rotate identities by policy rather than panic — use short-lived tokens, not embedded credentials.

Why it’s worth the setup:

• Faster, safer cross-cloud requests with no static secrets
• Unified audit trails across Azure AD and Google IAM
• Automatic scaling from zero without manual webhook routing
• Predictable latency since both services handle auth natively
• Easier SOC 2 and ISO 27001 compliance through identity-based access

Developers love it because it kills the need for yet another credentials vault or glue service. They deploy faster, debug quicker, and skip the “whose keys are these?” Slack threads. Less context switching means higher velocity and cleaner CI/CD pipelines.

Platforms like hoop.dev turn those access rules into guardrails that enforce policy automatically. You describe your intent — which service should talk to which — and hoop.dev ensures your requests follow identity-aware boundaries. No guesswork, just consistent cross-cloud access control.

How do I connect Azure App Service with Cloud Run?
Use OIDC-based federation between Azure Managed Identities and Google service accounts. Configure your App Service to issue tokens for Cloud Run’s audience, and assign the Cloud Run invoker role to that mapped identity.

Is Azure App Service Cloud Run integration secure?
Yes. Encryption is handled on both ends, and authentication happens with signed OIDC tokens instead of static secrets. It is as secure as any enterprise single sign-on flow when configured properly.

When identity replaces credentials, multi-cloud stops feeling like duct tape and starts feeling like architecture.

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.