Development environment in GCP with IAP

When developing my Glassdoor clone Compared, one of the goals was to deploy it in a production-grade environment to gain insight into how it is done. I decided on deploying on GCP, went through all the steps, eventually built a pipeline for it, and it worked fine.

However, I didn’t want my app to be public yet, as it was still in development.

I needed a way I could see my changes in a private and secure development environment that would mimic the production conditions.

My first idea and attempt to solve this was with a VPN and VPC. After thorough research and implementation, it was almost done, but something felt wrong. Sure, it was the traditional and proven method of securing access to an app or files, but I imagined that a large cloud provider such as GCP would have had a better, more modern solution.

I imagined since Google had such a robust OAuth system that there would be a solution in their services to put a web service behind an auth screen, as if one were logging into their Gmail account.

Turns out a service like this does exist, IAP, aka Identity-Aware Proxy.

Using IAP, it is possible to assign access to specific email accounts associated with a Google account, such as a Gmail account, by giving them the IAP-secured Web App User role.

With this setup, I could seamlessly have a Cloud Run service with an identical setup to my production be private and easily accessible.

And it was surprisingly easy to set up, less than half an hour with no prior knowledge about IAP.

Assuming a correctly set up Cloud Run service with its domain mapping done, you should see the service appear in Security > IAP (service needs to be enabled first, and there’s some straightforward configuration). At first, it will have an error by default, this can simply be fixed by turning on the IAP toggle button.

After IAP has been toggled, any user trying to access the application will be met with the Google auth screen. To grant access to a user, select the service you want and add a principal with the role IAP-secured Web App User.

It is also very simple to add expiration conditions to this access, such as a set expiration date, or set number of hours of access from moment of addition.

Next, make sure the IAP service account has permission for the role Cloud Run Invoker in the Cloud Run service. It should look like [email protected].

The last step in this IAP setup is to restrict access to authorized users with Cloud IAM on the Security tab of the service.

Now, the app is secure if accessed from the attributed domain.

However, it is also a good idea in almost all scenarios to disable access to the app through the run.app URL that is provided by default for a service. This can be done in the Networking tab. Make sure to select Internal and check to allow traffic from external Application Load Balancers.

Otherwise, the app would be protected when accessed from the “real” URL, but the xyz.run.app URL would still be unsecured.

And so, IAP is what I have been using to secure my app, both frontend and backend, from unsecured access. There is support to connect to an AD and grant access to groups and not just individuals. One could also use IAP under the right conditions to secure access to an internal company website and not just necessarily a development branch of a public facing one.