Workaround: Adding config for IAP OAuth Consent screen to TF

workaround_iap_oauth_consent_screen_config_in_terraform.md

Background

The OAuth consent screen is a prompt that appears when a user is asked to grant or deny access to their data by an app. The screen includes: A summary of the project, The project's policies, and The requested authorization scopes of access.

Within GCP, the OAuth consent screen contains branding information for users and is known as a brand. Brands can be limited to internal users or public users. An internal brand makes the OAuth flow accessible to someone who belongs to the same Google Workspace organization as the project. source.

OAuth Consent screen can be accessed via url: https://console.cloud.google.com/apis/credentials/consent?project=[replace-with-your-project-id]

The problem

Terraform is unable to create the brand using resource google_iap_brand where it will receive an error: Error: Error creating Brand: googleapi: Error 400: Request contains an invalid argument. There is an open bug for this hashicorp/terraform-provider-google#20204.

Subsequently when we tried to issue the command directly via the Google IAP API, we run into an issue where the OAuth credentials can only be created if the OAuth consent screen (what we are trying to programmatically configure) is configured. In addition, the Google IAP API does not support deletion of these resources which meant we couldn't create them first via the API and then remove them to add them in programmatically.

The workaround

NOTE: These steps only work for Internal brands (!Public). We were able to create the Brand/OAuth consent details manually via the UI and then import into Terraform so it could monitor the configuration.

Steps we took for this:

1. Navigate to OAuth consent screen config page: https://console.cloud.google.com/apis/credentials/consent?project=[replace-with-your-project-id]

2. Follow the wizard to configure as desired. Fill in the following fields and click Save and Continue.

• App name
• User support email: make sure that the person configuring this is an owner for the email address that needs to be setup

(click next)

• User type: Internal

(click next)

• Developer contact information

(click next)

• Review User data policy and check to agree

(click continue and then create)

4. OAuth consent is now configured! You will be redirected to the OAuth Overview screen.

• NOTE: Google has noted the following on their credentials configuration page: "It may take 5 minutes to a few hours for settings to take effect".

5. Next, You will need to interact with the Google IAP APIs. Pull up Postman or any tool of your choice for interacting with the APIs.

• If you do use Postman, I recommend this quick start guide which walks through setting up OAuth 2.0 (Steps 3 and 4)

6. Submit a GET request to get a list of your GCP project brands. Refer to the API docs for Method: projects.brands.list

Your response should be something like:

{
    "brands": [
        {
            "name": "projects/[same-as-brand-id]/brands/[brand-id]",
            "supportEmail": "[user-support-email]",
            "applicationTitle": "[app-name]",
            "orgInternalOnly": true
        }
    ]
}

Make note of the brand-id to be used for a later step.

7. Switch over to where your IDE/Code editor where you are working with Terraform.

8. You will need to add an import block in your terraform config files with the following snippet. Make note of all the replace- placeholders and swap those in with your corresponding values.

import {
  to = google_iap_brand.[replace-with-tf-name-you-want]
  id = "projects/[replace-with-gcp-project-id]/brands/[replace-with-brand-id]"
}

9. In a terminal, navigate to the directory where your terraform config is located (and where you added the import block to).

• NOTE: We will be using terraform CLI for the next step. If you don't have that configured, refer to these steps.

10. Run the following command which will execute the import block and generate the config code for any resources that don't already exist in the configuration.

• Update the filename before running the command.

terraform plan -generate-config-out=[replace-with-filename].tf  

11. Open up the file with the generated code. You can copy that to any existing terraform file or keep the generated file - up to you. You can now follow the process to get these changes applied with terraform. The Terraform plan would show as config being imported but no changes to the environment.

• NOTE: Current Google IAP API does not support destroying the brand via the API. If there is a change to any of the TF fields for this resource, you may need to remove the resource block (won't actually delete the brand) and then re-import it. The benefit of doing this is to catch any drift/changes in the environment.

12. Once the TF config has been applied, you can remove the import block from the TF config. The subsequent terraform plan that runs when removing the import block will yield no infrastructure changes.

All done :)