Access control with Identity and Access Management

Preview

This product or feature is subject to the "Pre-GA Offerings Terms" in the General Service Terms section of the Service Specific Terms. Pre-GA products and features are available "as is" and might have limited support. For more information, see the launch stage descriptions.

This page describes access control with Identity and Access Management (IAM) for the GitLab on Google Cloud integration.

Overview

IAM lets you grant granular access to specific Google Cloud resources and helps prevent access to other resources. IAM lets you adopt the security principle of least privilege, which states that nobody should have more permissions than they actually need.

For more information on how IAM works in Google Cloud, see IAM overview.

Control access to Google Cloud

If you followed the steps in the GitLab tutorial Google Cloud workload identity federation and IAM, then many of the standard GitLab claims like user_access_level have already been mapped to Google Cloud attributes. You don't need to take further action unless you want to add custom controls outside the initial setup.

If you want fine-grained control of who can access Google Cloud from your GitLab organization, you can set principals based on the GitLab custom attributes for the GitLab on Google Cloud integration using Common Expression Language (CEL).

For example, to allow users with the maintainer role in GitLab to push artifacts to Artifact Registry from the GitLab project gitlab-org/my-project:

1. In the Google Cloud console, go to the Workload Identity Federation page.

   Go to Workload Identity Federation

2. In the Display name column, click the name of your workload identity pool.

3. In the Providers panel, click the Edit icon next to the workload workload identity provider you want to edit.

   The Provider details page opens.

4. In the Attribute mapping section, click Add mapping.

5. In the Google N field, enter:

   attribute.my_project_maintainer
   

6. In the OIDC N field, enter the following CEL expression:

   assertion.maintainer_access=="true" && assertion.project_path=="gitlab-org/my-project"
   

7. Click Save.

   The Google attribute my_project_maintainer is mapped to the GitLab claims maintainer_access==true and the project_path=="gitlab-org/my-project".

8. In the Google Cloud console, go to the IAM page.

   Go to IAM

9. Click Grant access.

10. In the New principals field, enter the principal set including the attribute.my_project_maintainer/true in the following format:

    principalSet://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_ID/attribute.my_project_maintainer/true
    

    Replace the following:

    • PROJECT_NUMBER with your Google Cloud project number. To find your project number, see Identifying projects.
    • POOL_ID with your workload identity pool ID.

11. In the Select a role field, select the Artifact Registry Writer role (roles/artifactregistry.writer).

12. Click Save.

    The role is granted to the principal set containing users with the maintainer role in GitLab on the project gitlab-org/my-project.

To prevent your other GitLab projects from pushing artifacts to Artifact Registry, you can view your IAM policies in the Google Cloud console, and remove or edit roles as required.

View your Identity and Access Management policies

In the Google Cloud console, go to the IAM page.

Go to IAM

The Identity and Access Management permissions page opens.

You can select View by principals or View by roles.