Cloud Run and IAP

Identity Aware Proxy(IAP) is a simple way to secure applications running on Google Cloud. It is way simpler than going through the mechanics of setting up a OAuth2 authorization code flow.

IAP is a little tricky to set-up for Cloud Run Applications though, there is no simple option to turn it on for an existing service. Instead what needs to be done is the following:

1. A Backend service has to be created pointing to the Serverless Network endpoint group (Serverless NEG) pointing to the Cloud Run service
2. An external or internal https load balancer has to be set-up on the top of this NEG.
3. IAP then can be enabled for the Backend Service

source: https://cloud.google.com/iap/docs/concepts-overview

This is much more involved than for say an App Engine based application today, but the pain is on the set-up side, not the application side. From an application perspective, Authentication just works, it can retrieve the user identity using http headers or just ignore them if that is not important for the working of the application.

Sample Cloud Run Application

Let’s start by deploying a hello world application to Cloud Run, using the following command:

gcloud run deploy hello --image us-docker.pkg.dev/cloudrun/container/hello --region=us-west1

Assuming that the deploy goes through smoothly, the url of the application can now be obtained from here —

gcloud run services describe hello --format 'value(status.url)' --region=us-west1

Accessing this page, should look like this:

The application is open to the internet and there is no prompt to login to access the site.

Exposing a Serverless Network Endpoint Group

A Network endpoint group represents a group of instances that can handle an applications traffic, since Cloud Run is a serverless service, think of Serverless Network endpoint group as an abstracted set of instances.

gcloud compute network-endpoint-groups create neg-hello-us-west1 \
       --region=us-west1 \
       --network-endpoint-type=serverless  \
       --cloud-run-service=hello

Creating a Backend Service

A Backend Service defines how a load balancer distributes traffic to a set of instances. This can be created using the following commands:

gcloud compute backend-services create hello-backend-service --global

gcloud compute backend-services add-backend hello-backend-service \
       --global \
       --network-endpoint-group=neg-hello-us-west1 \
       --network-endpoint-group-region=us-west1

Creating a Global Https Loadbalancer

Now that a Backend Service has been created, the next step is to create a Global Https loadbalancer pointing to this Backend service:

I am using a self signed cert for a dummy “mysite.com” domain which can be generated using the following command:

openssl req -x509 -newkey rsa:2048 -sha256 -days 3650 -nodes \
  -keyout mysite.key -out mysite.crt -subj "/CN=mysite.com" \
  -addext "subjectAltName=DNS:mysite.com"

and an entry in my local /etc/hosts to simulate mysite.com pointing to the ip of the loadbalancer.

Alright, now that the loadbalancer is in place, accessing https://mysite.com resolves back to the Cloud Run app without needing any authentication still, the next few steps will enable IAP.

Enabling IAP

One of the pre-requisites to enabling IAP is to register the domain with the OAuth2 consent screen:

And the IAP can now be enabled for the Backend service:

Once enabled, accessing the service should now lead to a login page to be displayed:

Now which users are allowed to access the site, it will be any user associated with the “IAP-secured Web App User” role:

That should be it, this user will be allowed to login cleanly and access the secured web page.

Conclusion

IAP provides a very simple way to secure a Web Application, without needing to deal with the complications of an OAuth2 flow. Although the mechanics of setting it up is involved at the level of infrastructure, the application itself remains simple.