## Problem Currently, we require users to create and use a personal access token (PAT) to apply the GAM and IAM integration setup scripts. The user effort of the whole setup process, excluding cognitive load and time on task, can be summarized as: 1. `20` steps for IAM, and another `20` steps for GAM. 2. Three contexts to switch between: integration setup screen, PAT screen, command line. For example, for the GAM setup script, to configure the IAM policies in Google Cloud, this is the current script: ```shell curl --request GET \ --header "PRIVATE-TOKEN: <your_access_token>" \ --data 'google_cloud_artifact_registry_project_id=<google_cloud_project_id>' \ --data 'enable_google_cloud_artifact_registry=true' \ --url "https://gitlab.com/api/v4/projects/${this.projectId}/google_cloud/setup/integrations.sh" \ | bash ``` And here are all the steps needed to set up the IAM and the GAM integration from scratch, starting from the GAM integration screen (see [Figjam](https://www.figma.com/file/o1WAMLsWtIXpGsdckfu7TU/Setup-scripts-for-GAR-and-IAM?type=whiteboard&node-id=1-1382&t=glkEEE8aGNDi9rMI-11)):  ## Proposal Remove the need for PAT from the GAM and IAM setup scripts. By doing that, we reduce user effort: 1. 50% less steps — `10` steps for IAM, `10` steps for GAM. 2. One less context to switch between — no need to go and create a PAT on the side. This results in less time on task and, in theory, less cognitive load. Taking the GAM setup example above, it could easily be replaced by just the `gcloud` commands (replacing the placeholders with the right information) — from https://docs.gitlab.com/ee/user/project/integrations/google_artifact_registry.html#iam-policies. ```shell gcloud projects add-iam-policy-binding '<your_google_cloud_project_id>' \ --member='principalSet://iam.googleapis.com/projects/<your_google_cloud_project_number>/locations/global/workloadIdentityPools/<your_workload_identity_pool_id>/attribute.guest_access/true' \ --role='roles/artifactregistry.reader' gcloud projects add-iam-policy-binding '<your_google_cloud_project_id>' \ --member='principalSet://iam.googleapis.com/projects/<your_google_cloud_project_number>/locations/global/workloadIdentityPools/<your_workload_identity_pool_id>/attribute.developer_access/true' \ --role='roles/artifactregistry.writer' ``` Without the need for PAT, here are all the steps needed to set up the IAM and the GAM integration from scratch, starting from the GAM integration screen (see [Figjam](https://www.figma.com/file/o1WAMLsWtIXpGsdckfu7TU/Setup-scripts-for-GAR-and-IAM?type=whiteboard&node-id=1-1383&t=glkEEE8aGNDi9rMI-11)): * For the IAM setup, this flow assumes the user accepts the default values for the Workload Identity Pool ID and Provider ID (e.g. `gitlab-my-project-name`). * For the GAM setup, this flow assumes the `gcloud` commands (seen above) are hydrated with the Google Cloud project number and workload identity pool ID from the IAM integration. * Without PAT and just `gcloud` commands, there's no need for two IAM setup modes (guided vs manual setup), which further simplifies the UX and implementation.