On March 13, Google made IAP on Cloud Run generally available as a direct integration. One flag. --iap. No load balancer, no serverless NEG, no backend service, no URL map. The entire authentication layer that used to require six Terraform resources and a managed SSL certificate now ships with the service itself.
I have been running IAP on Cloud Run the old way for months: global HTTPS load balancer, serverless NEG, backend service with IAP enabled, managed cert, forwarding rule. It works. It is also a remarkable amount of infrastructure for what amounts to "only let authorized users in." The new direct integration eliminates all of it. Deploy with --iap, grant the IAP service account run.invoker, done.
For anyone building internal tools on GCP, this is the change that makes Cloud Run the obvious default. The previous architecture was defensible but hard to justify for a two-person team running a finance app. Now it is a single flag on deploy. The security posture is identical: Google handles the authentication flow at the infrastructure layer, your application never sees unauthenticated traffic, and you get context-aware access policies (IP, geolocation, device posture) without writing a line of application code.
I run Cloudflare Access in front of IAP on my personal projects. Belt and suspenders. Cloudflare handles WAF, DDoS, and provides an additional identity check at the edge before traffic ever reaches GCP. IAP handles the Google-native authentication and authorization. Two layers, two vendors, two failure domains. Overkill for a personal project, but the pattern translates directly to production: if either layer fails or is misconfigured, the other still blocks unauthorized access. That kind of defense in depth used to require a load balancer to wire together. Now it just requires a DNS record pointing through Cloudflare and a --iap flag on deploy.