Cloud Run and the Identity Aware Proxy
Securing your internal apps for your org just got a whole lot easier.
This post is also available in “podcast” form here:
Securing Your Cloud Run Services Just Got Easier: Introducing Identity-Aware Proxy Integration
Google Cloud recently announced a game-changing integration: the Identity-Aware Proxy (IAP) now works directly with Cloud Run. This is fantastic news because it brings a powerful and straightforward way to protect your Cloud Run resources, making them accessible only to authorised users within your organisation (and even external collaborators you specify) without complex setups or custom authentication code.
If you're not familiar with IAP, let's explore some of its key benefits, now extended to your serverless Cloud Run deployments.
Key Benefits of Using IAP with Cloud Run
Embrace Zero Trust Security: IAP is a cornerstone of Google's own "BeyondCorp" zero-trust security model. This means moving beyond traditional network-based security. Instead of implicitly trusting requests from a "secure" network, IAP verifies every user and device attempting to access your Cloud Run application, regardless of their location – whether on the corporate network or remote. As anyone who has worked in cloud security knows, network security alone only gets you so far.
Simplified Access Control with IAM: IAP integrates seamlessly with Google Cloud's Identity and Access Management (IAM). This allows for centralised, fine-grained control over who can access your Cloud Run services. Essentially, if your organisation uses Google Workspace or Google Cloud identities, users can "Sign in with Google" to be authenticated. You control access by assigning specific IAM roles.
Protect Internal and Sensitive Applications: By forcing users to authenticate through IAP before they can invoke your Cloud Run service, your internal dashboards, admin tools, and sensitive applications are no longer directly exposed. Only successfully authenticated and authorised users can pass through IAP.
Reduced Need for VPNs: IAP can often eliminate the need for traditional VPNs to access internal applications. In many traditional setups, users must be on an internal network (often via VPN) to access applications. IAP changes this paradigm, allowing users to securely access Cloud Run services from anywhere once they've authenticated and been authorised through IAP.
Consistent Security Across Environments: IAP provides a consistent security posture. This applies to your Google Cloud applications, like those on Cloud Run, and can even extend to on-premise systems in certain IAP configurations. This capability further reduces VPN dependency for remote users needing access to secured on-premise applications.
Detailed Audit Trails: A crucial but often overlooked benefit is the detailed logging IAP provides. It records access attempts, which is invaluable for security monitoring, incident response, and meeting various compliance requirements.
Getting Started: It's Simpler Than You Think
Enabling IAP for Cloud Run is remarkably straightforward:
Enable IAP during Service Configuration:
New Service: When deploying a new Cloud Run service via the Google Cloud Console, you'll find an option to enable IAP in the "Security" or "Authentication" section.
Existing Service: For an existing service, you can edit its configuration and enable IAP, then update the service.
OAuth Consent Screen & Credentials (Prerequisite): If you haven't already done so for your project, you'll need to configure the OAuth consent screen. You'll also need to create OAuth 2.0 client IDs and secrets, which are fundamental for IAP to function.
Assign IAM Roles (Crucial): This is a critical step. You need to assign the
IAP-secured Web App Userrole (or other relevant IAP roles) to the appropriate principals. Principals can be individual users, but more commonly and highly recommended, you'll assign the role to Google Groups. This allows users in those groups to access the application through the proxy.Secure Your Ingress: In Cloud Run's settings, you configure ingress to control how your service receives traffic. While you might still have a publicly accessible URL for your Cloud Run service, IAP will intercept requests.
The Magic of IAP on Public URLs: This is where the new integration shines. Even if your Cloud Run service has a public URL that anyone could theoretically hit, IAP steps in before the request reaches your service. It forces an authentication challenge. If the user is signed in with a Google account that has the necessary permissions (e.g., is part of an authorised group), they are allowed through. Otherwise, access is denied.
Simplified Architecture: Previously, to achieve this level of protection for Cloud Run, you'd typically need to set up IAP on an external HTTPS Load Balancer, configure serverless network endpoint groups (NEGs), and manage the complexities of that infrastructure. Now, IAP can be applied more directly to Cloud Run, significantly simplifying the architecture for many use cases, especially for protecting services accessed by organisational users.
Granting Access to External Users
You're not limited to users within your Google Cloud organisation. If you have external contractors or collaborators using their own Google accounts, you can grant them access by adding their Google account email (as a principal) to the allowed list in IAP's IAM policy for the Cloud Run service, or preferably, by adding them to a Google Group that has been granted access.
Best Practices and Important Considerations
Principle of Least Privilege: Always grant only the minimum necessary access to your Cloud Run resources. Using Google Groups for managing access is highly recommended. It's much easier to manage group memberships than individual user permissions on each service.
Easy Access Revocation: For example, if User A and User B are in a group that allows access via IAP, and User B is a contractor whose engagement ends, you don't need to modify the Cloud Run service's IAP configuration. Simply remove User B from the Google Group. IAP validates the user's identity and group memberships on each request. As soon as they are removed from the group, their subsequent access attempts will be denied. No service redeployment is needed.
Caching Unauthenticated Content: Be cautious with caching. For internal applications protected by IAP, avoid using third-party CDNs that might cache and serve sensitive pages or data to unauthenticated users. If you do use CDNs, reserve them for non-sensitive static assets like public fonts, images, or CSS files, and ensure proper cache-control headers are used for anything that should remain private.
Limitations and Testing:
IAP may have limitations with certain services like Cloud CDN when used directly.
Specific integrations, for instance, if services like Pub/Sub need to invoke your IAP-protected Cloud Run service, might require additional IAM configuration for the service agent or invoking service account.
Thorough testing is always paramount. While the direct IAP integration for Cloud Run is generally available, it's always wise to test your specific configuration and access patterns to ensure they work as expected.
Cost: Here's more great news: Identity-Aware Proxy itself is offered at no additional cost by Google Cloud. 🎉 You are, of course, still responsible for the costs associated with running your Cloud Run services (compute, etc.).
Google Cloud Organisation Requirement: A key prerequisite for using IAP is that your Google Cloud project must be part of a Google Cloud Organisation. You typically cannot enable IAP with projects solely associated with a personal Gmail account without an organisation structure. Setting up an organisation is free but adds a layer of management, which is something to be aware of if you're primarily using Google Cloud for personal projects.
Real-World Example: Securing a QA Environment
One of my clients, was looking for a secure way to host their Quality Assurance (QA) testing environment. They were understandably anxious about deploying non-production-ready versions of their application to the public internet. Previously, we had a more complex setup involving load balancers and request filtering.
Now, with direct IAP integration for Cloud Run, all that complexity is gone. They can automatically deploy their QA versions to Cloud Run as often as needed. They have full confidence that only authorised users within their domain (specifically, members of their "QA Testers" Google Group, which is granted the IAP-secured Web App User role) can access these environments. It's a simple, secure, and cost-effective solution.
A Welcome Addition to the Cloud Run Ecosystem
Overall, the direct integration of Identity-Aware Proxy with Cloud Run is an awesome addition. Cloud Run continues to evolve rapidly, with new features and enhancements appearing frequently. This particular update is incredibly welcome, as it dramatically simplifies the process of creating securely protected applications for users within your organisation, without the overhead of managing intricate security configurations or infrastructure.
Getting started is super easy. When creating or updating your Cloud Run service, just enable IAP, configure the necessary OAuth settings if you haven't already, and assign permissions to your chosen principals (ideally, groups). That’s the core of it!
Quick end comment:
I originally dictated this blogpost since my ideas when writing content tend to come far faster than I type, so after I completed the dictation, I asked AI to transcribe and clean up the “ums” and “errs” and “ahs” from my voice notes. I’d love to hear what you think about that please use the poll below. Note that your answer and votes from others won’t be public.