We can manage project level and higher access via the IAM admin page.

• Turn IAP on and off:

To do so, we need certain permissions.

1. App Engine require appengine.applications.update
2. Compute Engine or Google Kubernetes Engine require compute.backendServices.update

Roles such as Project Editor, App Engine Admin, and Compute Network Admin grant us these permissions.

Though they allow turning IAP on and off, they don’t have the permissions to modify access policies.

In addition, we require the clientauthconfig.clients.create and clientauthconfig.clients.getWithSecret permissions to turn IAP on with the Cloud Console.

Manage access in the Cloud Console

In order to add or remove access, our Support Techs suggest following the below process.

Add access:

1. Initially, we go to the Identity-Aware Proxy page.
2. We select the resource to secure with IAP. The below selections secure a set group of resources:

   a) All Web Services.
   b) Backend Services.

3. Then on the Info panel, we add the email addresses to grant an Identity and Access Management role.
4. We apply access policy roles to the member from the following roles in the Select a role dropdown:

   a) Owner: Grants the same access as IAP Policy Admin.
   b) IAP Policy Admin: Grants administrator rights over IAP policies.
   c) IAP-Secured Web App User: Grants access to the app and other HTTPS resources that use IAP.
   d) Security Reviewer: Grants permission to view and audit IAP policies.

5. Once we finish adding email addresses and setting roles, we click Add

Remove access:

1. Firstly, we go to the Identity-Aware Proxy page.
2. Then we select the resource secured with IAP.
3. On the Info panel, we select the section that corresponds to the role we want to remove from a member.
4. In the expanded section, next to each user or group name to remove the role, we click Remove.
5. Then in the Remove member dialog that appears, we click Remove.

Manage access with the API

Moving ahead, let us see a standard set of methods IAM provides to create and manage access control policies.

• Resources and Permissions:

With the IAP API, we can apply IAM permissions to individual resources in an IAP-secured project.

Generally, if we grant the IAM permissions at a certain level, it applies to all levels underneath it.

For example, project-level permissions apply to all Google Cloud resources in the project. Access for project-level and above is managed in the IAM admin page but will display on the IAP admin page.

To access an IAP-secured app and use methods that update IAM policies, we need permission.

The iap.webServiceVersions.accessViaIAP permission grants access to the app.

On the other hand, we need iap.tunnelInstances.accessViaIAP permission if we use the IAP to control access to administrative services like SSH and RDP.

Each IAP resource has its own getIamPolicy and setIamPolicy permissions. They grant the ability to manage access policies for that resource and its children.

• Public access:

To grant everyone access to a resource, we add one of the following members to its access list:

1. allAuthenticatedUsers: Anyone who authenticates with a Google account or a service account.
2. allUsers: Anyone who is on the internet.

If we grant public access, IAP won’t generate Cloud Audit Logs logs for the request.

In addition, bindings that grant public access can’t have a condition associated with them.

For example, a policy that allows anyone accesses to a resource if the request path starts with /public/ is invalid.