Access control with IAM

This page describes access control with Identity and Access Management (IAM) in Artifact Registry.

Default permissions for Artifact Registry minimize setup effort when implementing a CI/CD pipeline. You can also integrate Artifact Registry with third-party CI/CD tools and configure the permissions and authentication required to access repositories.

If you use Artifact Analysis to work with container metadata, such as vulnerabilities found in images, see the Artifact Analysis documentation for information about granting access to view or manage metadata.

Before you begin

  1. Enable Artifact Registry, including enabling the API and installing the Google Cloud CLI.
  2. If you want to apply repository-specific permissions, then create an Artifact Registry repository for your packages.

Overview

IAM permissions and roles determine your ability to create, view, edit, or delete data in an Artifact Registry repository.

A role is a collection of permissions. You can't grant a principal permissions directly; instead, you grant them a role. When you grant a role to a principal, you grant them all the permissions that the role contains. You can grant multiple roles to the same principal.

Google Cloud default permissions

By default, the following permissions apply to Google Cloud CI/CD services in the same project as Artifact Registry:

  • Cloud Build permissions include permissions to upload and download artifacts.

If all your services are in the same Google Cloud project and the default permissions meet your needs, you don't need to configure permissions.

You must configure Artifact Registry permissions for these services if:

  • You want to use these services to access Artifact Registry in another project. In the project with Artifact Registry, grant the workload identity pool or service account for each service the required role. If connecting to Cloud Run, grant the Cloud Run Service Agent the required role.
  • You're using a GKE version that does not have built-in support for pulling images from Artifact Registry. See the GKE section for configuration instructions.
  • You want the default service account to have read and write access to repositories. See the following information for details:
  • You're using a user-provided service account for your runtime environments instead of the default service account. In the project with Artifact Registry, grant your service account the required role.

Third-party integration

For third-party clients, you must configure both permissions and authentication.

Traditionally, applications running outside Google Cloud use service account keys to access Google Cloud resources. However, service account keys are powerful credentials, and can present a security risk if they are not managed correctly.

Workload Identity Federation lets you use Identity and Access Management to grant external identities IAM roles, including the ability to impersonate service accounts. This approach eliminates the maintenance and security burden associated with service account keys.

Use Workload Identity Federation:

  1. Create a Workload Identity Federation pool.
  2. Create a Workload Identity Federation provider.
  3. Grant the appropriate Artifact Registry role to the workload identity pool to allow repository access. For more information, see Allow your external workload to access Google Cloud resources.
  4. If you need to access Artifact Registry for longer periods of time, then configure the OIDC token expiration time to a longer period in your credential configuration.

  5. Configure your third-party client to authenticate with Artifact Registry.

Use a service account:

  1. Create a service account to act on behalf of your application, or choose an existing service account that use for your CI/CD automation.
  2. Grant the appropriate Artifact Registry role to the service account to provide repository access.

  3. Configure your third-party client to authenticate with Artifact Registry.