Hello and welcome. Identity-Aware Proxy, or IAP, provides authorization and authentication for a company's internal-facing HTTPS-based services.

Let's unpack this. Picture this. You're a systems engineer and you've been building services used inside the company by different departments and even some contractors. The company is moving exclusively to Google Cloud, which means all of your new and existing services need to run inside of Google Cloud.

Now, skipping over all of the implementation stuff that is going to be a massive headache, let's just imagine we're at the endpoint. We have our HTTPS-based applications running on the different GCP compute services. We have something running on App Engine, we have something running on Compute Engine, we even have some things in Kubernetes Engine.

How do we manage access to these different services? Remember, they're only used by employees and contractors. So, you're naturally reluctant to have them publicly facing, especially considering that some might not have any off mechanism at all, because they're only expected to be used from inside of the company's network.

Now, it's common here, the first thought might be to use a VPN, though the introduction of a VPN adds overhead for users and operators. Now, a potentially simpler solution would be to send requests through a proxy that can check the identity of the user making the request, which is basically what identity-aware proxy does.

Identity-aware proxy or, again, IAP, is designed to make HTTPS-based services publicly available to authorized individuals. Let's see how that works.

In order to use IAP for a given project, the API needs to be enabled. Once enabled, we can select the resources that we want IAP to protect. Some of the resources that it can protect include App Engine applications, Compute Engine instances, and anything behind an HTTPS-based load balancer.

When an HTTPS-based request is made to an IAP protected resource, the request, as well as some additional info, is sent over to the IAP authentication server. Once here, the request is inspected for IAP credentials.

If no credentials are found, then the user is presented with the Google account sign-in flow, so that they can authenticate. IAP works with two different types of identities, which are Google and external. Though we're only going to focus on Google identities for this lesson.

Once IAP authenticates the user, it adds an access token to a cookie for future requests. It also checks the identity attached to the request to see if they're authorized to access the requested resource. Access to the IAP protected services can be specified at the resource or project levels.

Applying the IAP secured web app user role to an organization member gives them project-wide access to all of the other IAP resources that are protected inside of that project. Applying the IAP secured web app user role to a member and resource on the IAP page, allows access to just the specific resource.

At this point, the request is allowed to be sent through to the service. And from here, the user can interact with the app like normal. If the service they're using doesn't include its own additional user restrictions, then the user has full access. Depending on the app, you may be willing to stop here, that might be all you need. After all, not every application needs additional user restrictions. However, by stopping here, there is a concern about what happens if IAP is disabled or misconfigured. Because IAP, at this point, is the only thing that's preventing the resource from being consumable to the public internet.

To help here, we can use signed headers, which are based on JSON Web tokens, also called JWTs and sometimes pronounced as jot, singular, or jots, plural. JWTs here provide us with a second level of security by sending the JWT in a request header. Now, it's our responsibility to validate that token.

By verifying the token, we know that this information was in fact sent by Google. Because the token contains the identity information for the request, namely, email and ID, we can use that inside of our application if needed.

IAP protected services running in App Engine standard can obtain the same identity information from the user's API, which will save a little time not having to do that validation for the JWT. IAP works with both user and service identities. User identities work with web, mobile, and desktop apps. The IAP web flow uses an OAuth2 consent screen to authenticate an identity. The mobile flow uses the Google sign-in API and passes a generated OAuth2 client ID. For all other types, we need to create an OAuth2 client ID and client secret. And with these two values, we can programmatically authenticate using Google's OAuth2 sign-in API.

Service identities are similar to the user option, in that it passes an authorization token in the request header. Though, the service account doesn't go through the OAuth2 sign-in process to obtain its token as a user would.

Let's recap what we've covered so far. IAP allows us to protect specific GCP resources that communicate via HTTPS. Now, this includes Compute Engine, App Engine, and anything that will run behind the HTTPS load balancer. Which means that this will work with GKE as well.

Protection in this context refers to authentication and authorization. IAP checks the identity of whomever is making the HTTPS requests to an IAP enabled resource. Authorization is determined based on the IAP secured web app user role, which can be set at the project or resource level.

IAP uses JWT as a secondary layer of protection and as a means of passing the identity information to the service.

There are multiple reasons this secondary level of protection is required. First, IAP could become disabled due to human error. Second, a misconfigured firewall could bypass IAP altogether. If the service is running on Compute Engine instances, then services on the same network could interact via IP address and bypass IAP. Also, code running on the same virtual machine could access the service at localhost. So, using signed headers is an important part of this layered security approach to make sure this isn't bypassed in some way.

All right, with that, let's wrap up this lesson. Thank you so very much for watching and I will see you in another lesson.

Lectures

• Introduction
• Service Discovery with Kubernetes Engine & Compute Engine
• Configuring Applications with Instance Metadata
• Developing with the GCloud CLI and Cloud Shell
• Integrating Apps with the GCP REST API
• Summary