このページは Cloud Translation API によって翻訳されました。

IAM を使用したアクセス制御

このページでは、Artifact Registry で Identity and Access Management（IAM）によるアクセス制御について説明します。

Artifact Registry のデフォルト権限により、CI/CD パイプラインの実装時の設定作業は最小限に抑えられています。Artifact Registry をサードパーティの CI/CD ツールと統合し、リポジトリへのアクセスに必要な権限と認証を構成することもできます。

Artifact Analysis を使用してコンテナメタデータ（イメージで見つかった脆弱性など）を処理する場合は、Artifact Analysis のドキュメントで、メタデータの表示や管理権限を付与する方法をご確認ください。

始める前に

Artifact Registry を有効にします。これには API の有効化と、Google Cloud CLI のインストールが含まれます。
リポジトリ固有の権限を適用する場合は、パッケージ用の Artifact Registry リポジトリを作成します。

概要

IAM の権限とロールにより、Artifact Registry リポジトリ内のデータの作成、表示、編集、削除が可能かどうかが決まります。

ロールとは、一連の権限のことです。プリンシパルに直接権限を付与することはできません。代わりに、ロールを付与します。ロールをプリンシパルに付与する際には、ロールに含まれているすべての権限がプリンシパルに付与されます。同じプリンシパルに複数のロールを付与できます。

Google Cloud のデフォルトの権限

デフォルトでは、次の権限が Artifact Registry と同じプロジェクト内の Google Cloud CI/CD サービスに適用されます。

Cloud Build の権限には、アーティファクトのアップロードとダウンロードを行うための権限が含まれています。

Compute Engine、サポートされている Google Kubernetes Engine のバージョン、Cloud Run は、Compute Engine のデフォルトのサービスアカウントを使用します。このアカウントには、ストレージに対する読み取り専用アクセス権が付与されています。

すべてのサービスが同じ Google Cloud プロジェクト内にあり、デフォルトの権限がニーズを満たしている場合は、権限を構成する必要はありません。

次の場合は、これらのサービスに対して Artifact Registry の権限を構成する必要があります。

これらのサービスを使用して、別のプロジェクトの Artifact Registry にアクセスする必要がある。Artifact Registry を使用するプロジェクトで、Workload Identity プールまたは各サービスのサービスアカウントに、必要なロールを付与します。Cloud Run に接続する場合は、Cloud Run サービスエージェントに必要なロールを付与します。

Artifact Registry からイメージを pull する組み込みのサポートがない GKE バージョンを使用している。構成手順については、GKE セクションをご覧ください。
デフォルトのサービスアカウントにリポジトリへの読み取りと書き込みのアクセス権を付与する必要がある。詳しくは以下をご覧ください。
- Compute Engine
- GKE
デフォルトのサービスアカウントではなく、ランタイム環境にユーザー指定のサービスアカウントを使用しています。Artifact Registry を使用するプロジェクトで、必要なロールを付与します。

サードパーティとの統合

サードパーティクライアントの場合は、権限と認証の両方を構成する必要があります。

従来の方法では、Google Cloud の外部で実行されているアプリケーションは、サービスアカウントキーを使用して Google Cloud リソースにアクセスします。ただし、サービスアカウントキーは強力な認証情報であり、正しく管理しなければセキュリティ上のリスクとなります。

Workload Identity 連携では、Identity and Access Management（IAM）を使用して外部 ID に IAM ロールを付与して、サービスアカウントの権限を借用するといったことができます。これにより、サービスアカウントキーに関連するメンテナンスとセキュリティの負担がなくなります。

Workload Identity 連携を使用する:

Workload Identity 連携プールを作成します。
Workload Identity 連携プロバイダを作成します。
リポジトリへのアクセスを許可するには、Workload Identity プールに適切な Artifact Registry ロールを付与します。
Artifact Registry で認証するようにサードパーティクライアントを構成します。
- コンテナイメージ: Docker、Helm
- 言語パッケージ: Java、 Node.js、 Python、 Go
- OS パッケージ: Debian、RPM
- その他: Kubeflow パイプラインテンプレート

サービスアカウントを使用する:

アプリケーションに代わって動作するサービスアカウントを作成するか、CI/CD の自動化に使用する既存のサービスアカウントを選択します。
適切な Artifact Registry のロールをサービスアカウントに付与して、リポジトリへのアクセスを許可します。
Artifact Registry で認証するようにサードパーティクライアントを構成します。
- コンテナイメージ: Docker、Helm
- 言語パッケージ: Java、 Node.js、 Python、 Go
- OS パッケージ: Debian、RPM
- その他: Kubeflow パイプラインテンプレート

Google Cloud での GitLab

GitLab on Google Cloud の統合では、Google Cloud 上の GitLab ワークロードの認可と認証に、Workload Identity 連携を使用します。サービスアカウントやサービスアカウントキーは必要ありません。このパートナーシップで Workload Identity 連携がどのように使用されているかについては、Google Cloud Workload Identity 連携と IAM ポリシーをご覧ください。

Workload Identity 連携の設定と GitLab on Google Cloud に必要な IAM ロールについては、GitLab チュートリアルの Google Cloud Workload Identity 連携と IAM ポリシーをご覧ください。

Artifact Registry リポジトリを接続するには、GitLab チュートリアルの Google Artifact Registry をご覧ください。

ロールと権限

すべての Artifact Registry API メソッドでは、リクエストを行うプリンシパルにリソースの使用に必要な権限が必要です。権限は、リソースに対する事前定義されたロールをプリンシパルに付与するポリシーを設定することでプリンシパルに付与されます。

Google Cloud プロジェクトまたは Artifact Registry リポジトリでロールを付与できます。

事前定義された Artifact Registry ロール

IAM には、特定の Google Cloud リソースに対するアクセス権を付与する事前定義ロールが用意されています。

pkg.dev ドメインのリポジトリには、次の事前定義ロールを使用します。

ロール	説明
Artifact Registry 読み取り（`roles/artifactregistry.reader`）	アーティファクトの表示と取得、リポジトリのメタデータの表示。
Artifact Registry 書き込み（`roles/artifactregistry.writer`）	アーティファクトを読み書きします。
Artifact Registry リポジトリ管理者（`roles/artifactregistry.repoAdmin`）	アーティファクトの読み取り、書き込み、削除。
Artifact Registry 管理者（`roles/artifactregistry.admin`）	リポジトリとアーティファクトの作成および管理。

次の追加の事前定義ロールには、Container Registry から Artifact Registry に移行するために必要な権限が含まれています。

ロール	説明
Container Registry -> Artifact Registry 移行管理者（`roles/artifactregistry.containerRegistryMigrationAdmin`）	移行ツールの実行に必要なすべての権限が含まれています
Artifact Registry の Create-on-push Writer（`roles/artifactregistry.createOnPushWriter`）	アーティファクトを読み書きします。`gcr.io` URL に push するときに gcr.io リポジトリを作成します。
Artifact Registry の Create-on-push リポジトリ管理者（`roles/artifactregistry.createOnPushRepoAdmin`）	アーティファクトの読み取り、書き込み、削除。gcr.io リポジトリの作成

各ロールの個々の権限の完全なリストについては、Artifact Registry のロールをご覧ください。gcloud iam roles describe コマンドを使用して、各ロールの権限のリストを表示することもできます。

IAM の基本ロール

基本ロールは、IAM の導入前に存在していた高い権限を持つロールです。本番環境では基本ロールを付与すべきではありません。基本ロールは、開発環境またはテスト環境で付与してください。

可能な限り、リポジトリアクセスに事前定義ロールを使用して、ユーザーとサービスアカウントに必要な権限のみを付与します。

基本ロールの詳細については、IAM の基本ロールと事前定義ロールのリファレンスをご覧ください。

ロールを付与しています

同じロールがプロジェクト内のすべてのリポジトリに適用される場合は、プロジェクトレベルでロールを付与します。一部のアカウントに異なるレベルのアクセス権が必要な場合は、リポジトリレベルでロールを付与します。

仮想リポジトリにロールを付与する場合、これらのロールは、個々のリポジトリの権限に関係なく、仮想リポジトリから利用可能なすべてのアップストリームリポジトリに適用されます。

gcloud コマンドを使用してロールを付与する場合は、プリンシパルに対して 1 つのロールバインディングを指定するか、リソースの許可ポリシーを取得して変更し、変更した許可ポリシーを設定することで、ポリシーを大規模に変更できます。詳細については、プログラムでの複数のロールの付与または取り消すをご覧ください。

プロジェクト全体のロールの付与

同じ権限がプロジェクト内のすべてのリポジトリに適用される場合は、プロジェクトレベルでロールを付与します。

ユーザーまたはサービスアカウントをプロジェクトに追加し、Artifact Registry のロールを付与するには:

コンソール

Google Cloud コンソールで [IAM] ページを開きます。
[IAM] ページを開く
[プロジェクトを選択] をクリックし、Artifact Registry が実行されているプロジェクトを選択して、[開く] をクリックします。
[追加] をクリックします。
メールアドレスを入力します。個人、サービスアカウント、Google グループをプリンシパルとして追加できます。
プリンシパルのロールを選択します。最小権限のセキュリティ原則に従って、必要な Artifact Registry リソースにアクセスするために最小限の権限を付与することを検討してください。Artifact Registry の事前定義ロールと権限については、Artifact Registry の事前定義ロールをご覧ください。
[保存] をクリックします。

gcloud

In the Google Cloud console, activate Cloud Shell.

Activate Cloud Shell

At the bottom of the Google Cloud console, a Cloud Shell session starts and displays a command-line prompt. Cloud Shell is a shell environment with the Google Cloud CLI already installed and with values already set for your current project. It can take a few seconds for the session to initialize.
単一のプリンシパルにロールを付与するには、次のコマンドを実行します。
```
gcloud projects add-iam-policy-binding PROJECT \
   --member=PRINCIPAL \
   --role=ROLE
```
ここで
- PROJECT は、Artifact Registry が実行されているプロジェクトの ID です。
- PRINCIPAL は、バインディングを追加するプリンシパルです。user|group|serviceAccount:email または domain:domain の形式を使用します。
  
  例: user:test-user@gmail.com、group:admins@example.com、serviceAccount:test123@example.domain.com、または domain:example.domain.com。
- ROLE は、付与するロールです。
詳細については、add-iam-policy-binding のドキュメントをご覧ください。

ポリシーファイルを使用してロールを付与するには、プログラムでの複数のロールの付与または取り消しをご覧ください。

リポジトリ固有のロールの付与

ユーザーまたはサービスアカウントに、プロジェクト内のリポジトリごとに異なるレベルのアクセス権を付与する場合は、リポジトリレベルのロールを付与します。

コンソール

特定のリポジトリへのアクセス権を付与するには:

Google Cloud コンソールで [リポジトリ] ページを開きます。

[リポジトリ] ページを開く
適切なリポジトリを選択します。
情報パネルが表示されていない場合は、メニューバーで [情報パネルを表示] をクリックします。
[権限] タブで、[プリンシパルを追加] をクリックします。
メールアドレスを入力します。個人、サービスアカウント、Google グループをプリンシパルとして追加できます。
プリンシパルのロールを選択します。最小権限のセキュリティ原則に従って、必要な Artifact Registry リソースにアクセスするために最小限の権限を付与することを検討してください。Artifact Registry の事前定義ロールと権限の詳細については、Artifact Registry の事前定義ロールをご覧ください。
[保存] をクリックします。

gcloud

In the Google Cloud console, activate Cloud Shell.

Activate Cloud Shell

At the bottom of the Google Cloud console, a Cloud Shell session starts and displays a command-line prompt. Cloud Shell is a shell environment with the Google Cloud CLI already installed and with values already set for your current project. It can take a few seconds for the session to initialize.
個別のポリシーバインディングの IAM セットを設定する、またはポリシーファイルを使用することができます。

単一のプリンシパルにロールを付与するには、次のコマンドを実行します。
```
gcloud artifacts repositories add-iam-policy-binding REPOSITORY \
   --location=LOCATION \
   --member=PRINCIPAL \
   --role=ROLE
```
ここで
- REPOSITORY はリポジトリの ID です。
- PRINCIPAL は、バインディングを追加するプリンシパルです。user|group|serviceAccount:email または domain:domain の形式を使用します。
  
  例: user:test-user@gmail.com、group:admins@example.com、serviceAccount:test123@example.domain.com、または domain:example.domain.com。
- ROLE は、付与するロールです。
- LOCATION は、リポジトリのリージョンまたはマルチリージョンのロケーションです。
たとえば、ユーザー write@gmail.com のロール roles/artifactregistry.writer に、ロケーション --us-west1 のリポジトリ my-repo を持つ IAM ポリシーバインディングを追加するには、次のコマンドを実行します。
```
gcloud artifacts repositories add-iam-policy-binding my-repo \
--location=us-west1 --member=user:write@gmail.com --role=roles/artifactregistry.writer
```
ポリシーファイルを使用してロールを付与するには、複数のロールをプログラムで付与または取り消すで説明されている手順に沿って、gcloud artifacts repositories get-iam-policy コマンドと gcloud artifacts repositories set-iam-policy コマンドを使用します。

Terraform

google_artifact_registry_repository_iam リソースを使用して、IAM ポリシーを構成します。次の例では、リソース名が repo-account のサービスアカウントを定義し、リソース名が my-repo のリポジトリへの読み取りアクセス権を付与します。

Google Cloud で Terraform を初めて使用する場合は、HashiCorp ウェブサイトの Google Cloud スタートガイドページをご覧ください。

provider "google" {
    project = "PROJECT-ID"
}

resource "google_artifact_registry_repository" "my-repo"     {
  provider = google-beta

  location = "LOCATION"
  repository_id = "REPOSITORY"
  description = "DESCRIPTION"
  format = "FORMAT"
}

resource "google_service_account" "repo-account" {
  provider = google-beta

  account_id   = "ACCOUNT-ID"
  display_name = "Repository Service Account"
}

resource "google_artifact_registry_repository_iam_member" "repo-iam" {
  provider = google-beta

  location = google_artifact_registry_repository.my-repo.location
  repository = google_artifact_registry_repository.my-repo.name
  role   = "roles/artifactregistry.reader"
  member = "serviceAccount:${google_service_account.repo-account.email}"
}

ACCOUNT-ID はサービスアカウントの ID です。これは、サービスアカウントのメールアドレスフィールドの @ 記号の前の部分です。

その他の例については、google_artifact_registry_repository_iam リソースのドキュメントをご覧ください。

リポジトリへの公開アクセスを構成する

認証なしでインターネット上のすべてのユーザーが利用できるようすることが必要なアーティファクトがある場合は、一般公開するリポジトリに保存します。

公開読み取り専用アクセス権用のリポジトリを構成するには、プリンシパル allUsers に Artifact Registry 読み取りロールを付与します。また、ユーザーリクエストの割り当てに上限を設定することをおすすめします。これにより、1 人のユーザーがプロジェクトの全体的な割り当てを使い切ってしまうことを防ぐことができます。

コンソール

Google Cloud コンソールで [リポジトリ] ページを開きます。

[リポジトリ] ページを開く
適切なリポジトリを選択します。
情報パネルが表示されていない場合は、メニューバーで [情報パネルを表示] をクリックします。
[権限] タブで、[プリンシパルを追加] をクリックします。
[新しいプリンシパル] フィールドに「allUsers」と入力します。
[Artifact Registry 読み取り] ロールを選択します。
認証されていないユーザーによる不正使用を防ぐため、Artifact Registry API リクエストにユーザーごとの上限を設定します。手順については、使用量の上限設定をご覧ください。

gcloud

In the Google Cloud console, activate Cloud Shell.

Activate Cloud Shell

At the bottom of the Google Cloud console, a Cloud Shell session starts and displays a command-line prompt. Cloud Shell is a shell environment with the Google Cloud CLI already installed and with values already set for your current project. It can take a few seconds for the session to initialize.
次のコマンドを実行します。
```
gcloud artifacts repositories add-iam-policy-binding REPOSITORY \
--location=LOCATION --member=allUsers --role=ROLE
```
ここで
- REPOSITORY はリポジトリの ID です。
- ROLE は、付与するロールです。
- LOCATION は、リポジトリのリージョンまたはマルチリージョンのロケーションです。
たとえば、ロケーション --us-west1 のリポジトリ my-repo を一般公開として構成するには、次のコマンドを実行します。
```
gcloud artifacts repositories add-iam-policy-binding my-repo \
 --location=us-west1 --member=allUsers --role=roles/artifactregistry.reader
```
認証されていないユーザーによる不正使用を防ぐため、Artifact Registry API リクエストにユーザーごとの上限を設定します。手順については、使用量の上限設定をご覧ください。

ロールを取り消し中

リポジトリへのアクセス権を取り消すには、承認済みプリンシパルのリストからプリンシパルを削除します。

リポジトリから公開アクセスを削除するには、allUsers プリンシパルを削除します。

コンソール

権限を取り消す手順は次のとおりです。

Google Cloud コンソールで [リポジトリ] ページを開きます。

[リポジトリ] ページを開く
適切なリポジトリを選択します。
情報パネルが表示されていない場合は、メニューバーで [情報パネルを表示] をクリックします。
[権限] タブで、適切なプリンシパルを展開します。一般公開リポジトリを非公開にする場合は、allUsers プリンシパルを展開します。
[プリンシパルを削除] をクリックしてアクセス権を取り消します。

gcloud

In the Google Cloud console, activate Cloud Shell.

Activate Cloud Shell

At the bottom of the Google Cloud console, a Cloud Shell session starts and displays a command-line prompt. Cloud Shell is a shell environment with the Google Cloud CLI already installed and with values already set for your current project. It can take a few seconds for the session to initialize.
プロジェクトレベルでロールを取り消すには、次のコマンドを実行します。
```
gcloud projects remove-iam-policy-binding PROJECT \
   --member=PRINCIPAL \
   --role=ROLE
```
- PROJECT は、プロジェクト ID です。
- PRINCIPAL は、バインディングを削除するプリンシパルです。user|group|serviceAccount:email または domain:domain の形式を使用します。
  
  例: user:test-user@gmail.com、group:admins@example.com、serviceAccount:test123@example.domain.com、または domain:example.domain.com。
- ROLE は、取り消すロールです。
リポジトリのロールを取り消すには、次のコマンドを実行します。
```
gcloud artifacts repositories remove-iam-policy-binding REPOSITORY
   --location=LOCATION \
   --member=PRINCIPAL \
   --role=ROLE
```
ここで
- REPOSITORY はリポジトリの ID です。
- PRINCIPAL は、バインディングを削除するプリンシパルです。user|group|serviceAccount:email または domain:domain の形式を使用します。
  
  例: user:test-user@gmail.com、group:admins@example.com、serviceAccount:test123@example.domain.com、または domain:example.domain.com。
  
  リポジトリへの公開アクセス権を取り消すには、プリンシパル allUsers を指定します。
- ROLE は、取り消すロールです。
たとえば、--us-west1 ロケーションのリポジトリ my-repo を持つユーザー write@gmail.com のロール roles/artifactregistry.writer のポリシーバインディングを削除するには、次のコマンドを実行します。
```
gcloud artifacts repositories remove-iam-policy-binding my-repo \
   --location=us-west1 \
   --member=user:write@gmail.com \
   --role=roles/artifactregistry.writer
```
ロケーション --us-west1 で my-repo への公開アクセス権を取り消すには、次のコマンドを実行します。
```
gcloud artifacts repositories remove-iam-policy-binding my-repo \
   --location=us-west1 \
   --member=allUsers \
   --role=roles/artifactregistry.reader
```

タグを使用した条件付きのアクセス権の付与

プロジェクト管理者は、Google Cloud のリソースにタグを作成し、Resource Manager で管理できます。Artifact Registry リポジトリにタグ付けすると、管理者は IAM 条件を伴うタグを使用して、リポジトリに条件付きのアクセス権を付与できます。

個々のアーティファクトにタグ付けすることはできません。

詳細については、以下のドキュメントをご覧ください。

タグとアクセス制御を設定する管理者
- タグの作成と管理
- タグとアクセス制御
リポジトリにタグを適用するデベロッパー
- リポジトリのタグ付け

Google Cloud サービスとの統合

ほとんどの Google Cloud サービスアカウントでは、レジストリへのアクセスを構成するには、適切な IAM ロールを付与することのみ必要です。

Google Cloud サービスのデフォルトのサービスアカウント

Cloud Build や Google Kubernetes Engine などの Google Cloud サービスは、デフォルトのサービスアカウントまたはサービスエージェントを使用して、同じプロジェクト内のリソースを操作します。

次の場合は、権限をご自分で構成または変更する必要があります。

Google Cloud サービスが Artifact Registry とは異なるプロジェクトにある。
デフォルトの権限ではニーズが満たされない。
デフォルトのサービスアカウントではなく、ユーザー指定のサービスアカウントを使用して Artifact Registry を操作している。
組織のポリシーの構成により、デフォルトのサービスアカウントへのロールの自動付与がブロックされています。

通常、次のサービスアカウントは Artifact Registry にアクセスします。サービスアカウントのメールアドレスには、サービスが実行されているプロジェクトの Google Cloud プロジェクト ID またはプロジェクト番号が含まれます。

サービス	サービスアカウント	メールアドレス
App Engine フレキシブル環境	App Engine サービスアカウント	`PROJECT-ID`@appspot.gserviceaccount.com
Compute Engine	Compute Engine のデフォルトのサービスアカウント	`PROJECT-NUMBER`-compute@developer.gserviceaccount.com
Cloud Build	Compute Engine サービスアカウントまたは従来の Cloud Build サービスアカウント	組織の設定に応じて、デフォルトのサービスアカウントのメールアドレスは次のいずれかになります。 Compute Engine: `PROJECT-NUMBER`-compute@developer.gserviceaccount.com Cloud Build: `PROJECT-NUMBER`@cloudbuild.gserviceaccount.com 注: ビルドの実行に使用される Cloud Build のデフォルトサービスアカウントが、従来の Cloud Build サービスアカウントから Compute Engine のデフォルトサービスアカウントに変更されました。詳細については、Cloud Build サービスアカウントの変更をご覧ください。
Cloud Run	Cloud Run サービスエージェント `run.googleapis.com` のサービスエージェント。	service-`PROJECT-NUMBER`@serverless-robot-prod。iam.gserviceaccount.com
GKE	Compute Engine のデフォルトのサービスアカウントノードのデフォルトのサービスアカウント。	`PROJECT-NUMBER`-compute@developer.gserviceaccount.com

組織のポリシーの構成によっては、デフォルトのサービスアカウントにプロジェクトに対する編集者のロールが自動的に付与される場合があります。iam.automaticIamGrantsForDefaultServiceAccounts 組織ポリシー制約を適用して、自動的なロール付与を無効にすることを強くおすすめします。2024 年 5 月 3 日以降に組織を作成した場合、この制約はデフォルトで適用されます。

自動ロール付与を無効にする場合、デフォルトのサービスアカウントに付与するロールを決定し、これらのロールを付与する必要があります。

デフォルトのサービスアカウントにすでに編集者ロールが設定されている場合は、編集者ロールを権限の低いロールに置き換えることをおすすめします。サービスアカウントのロールを安全に変更するには、Policy Simulator を使用して変更の影響を確認してから、適切なロールを付与または取り消す操作を行います。

Compute Engine インスタンスへのアクセス権の付与

リポジトリにアクセスする VM インスタンスには、Artifact Registry 権限とストレージアクセススコープの両方が構成されている必要があります。

サービスアカウントのアクセスレベルはサービスアカウントに付与された IAM ロールによって決定されますが、VM インスタンスのアクセススコープによって、インスタンスの gcloud CLI とクライアントライブラリを使用して行われるリクエストのデフォルトの OAuth スコープが決定されます。そのため、アクセススコープでは、アプリケーションのデフォルト認証情報で認証する際に API メソッドへのアクセスをさらに制限できます。

Compute Engine では、次のデフォルトが使用されます。

Compute Engine のデフォルトのサービスアカウントが VM インスタンスの ID です。サービスアカウントのメールアドレスには、@developer.gserviceaccount.com というサフィックスが付加されています。
この動作を無効にしていない場合、このデフォルトのサービスアカウントには IAM の基本の編集者のロールがあります。
デフォルトのサービスアカウントで作成したインスタンスには、Compute Engine のデフォルトのアクセススコープ（ストレージへの読み取り専用アクセス権を含む）が設定されています。編集者のロールは通常、書き込み権限を付与するものであるのに対して、read-only ストレージアクセススコープは、インスタンスのサービスアカウントに対し、アーティファクトのダウンロードについて、同じプロジェクトのリポジトリからのみとする制限を課します。

次の場合に、サービスアカウントのアクセス範囲を構成する必要があります。

VM サービスアカウントが、別のプロジェクト内のリポジトリにアクセスする必要がある。
VM サービスアカウントは、リポジトリからアーティファクトを読み取る以外のアクションを実行する必要がある。これは通常、イメージを push するか Artifact Registry の gcloud コマンドを実行する必要がある VM にサードパーティツールを適用することによって実現します。

ロールを構成してアクセススコープを設定するには:

VM インスタンスを含むプロジェクトで、Compute Engine のデフォルトサービスアカウントの名前を取得します。サービスアカウントのメールアドレスには、@developer.gserviceaccount.com というサフィックスが付加されています。
リポジトリが含まれるプロジェクトで、サービスアカウントでリポジトリにアクセスできるように権限を付与します。
-scopes オプションを使用してアクセススコープを設定します。
1. VM インスタンスを停止します。インスタンスの停止をご覧ください。
2. 次のコマンドでアクセススコープを設定します。
```
gcloud compute instances set-service-account INSTANCE --scopes=SCOPE
```
  SCOPE は、適切な値に置き換えます。
  - Docker では、次のオプションがサポートされます。
    - storage-ro - イメージの pull のみを許可する読み取り権限を付与します。
    - storage-rw - イメージを push または pull するための読み取りと書き込みの権限を付与します。
    - cloud-platform - メタデータを含む Google Cloud サービス全体のデータを表示して管理します。
  - その他の形式の場合は、cloud-platform スコープを使用する必要があります。
3. VM インスタンスを再起動します。停止されたインスタンスの起動をご覧ください。

Google Kubernetes Engine クラスタへのアクセス権の付与

GKE クラスタとノードプールは、次の要件がすべて満たされていれば、追加の構成なしでコンテナを pull できます。

GKE が Artifact Registry と同じプロジェクトにある
ノードはデフォルトのサービスアカウント（Compute Engine のデフォルトサービスアカウント）を使用しています。
ノードが、ストレージへの読み取りアクセス権で作成されている。次のいずれかの方法で作成されたものである。
- Compute Engine のデフォルトのアクセススコープを使用する。
- cloud-platform アクセススコープまたはストレージへの読み取りアクセス権を含む別のスコープを付与する。
サポートされているバージョンの GKE を実行している

GKE 環境がこれらの要件を満たしていない場合は、Compute Engine のデフォルトサービスアカウントを使用しているか、ユーザーから提供されたアカウントをノードの ID として使用しているかによって、アクセス権を付与する手順が異なります。

デフォルトサービスアカウント

次の構成要件は、Compute Engine のデフォルトサービスアカウントに適用されます。

GKE が Artifact Registry とは異なるプロジェクトにある場合、必要な権限をサービスアカウントに付与します。
イメージを push するには、コンテナ以外の形式のリポジトリを操作するか、クラスタから gcloud コマンドを実行して、クラスタまたはノードプールを作成する際にサービスアカウントのアクセススコープを設定する必要があります。
GKE のサポートされているバージョンを使用していない場合は、imagePullSecrets を構成します。

ユーザー提供のサービスアカウント

ユーザー指定のサービスアカウントをクラスタの ID として使用する場合は、次の操作を行う必要があります。

Artifact Registry が実行されている Google Cloud プロジェクトから、サービスアカウントに必要な権限を付与します。
デフォルトでは、ユーザー提供のサービスアカウントを使用してクラスタまたはノードプールを作成すると、cloud-platform アクセススコープが付与されます。

gcloud container clusters create コマンドまたは gcloud container node-pools create コマンドで --scopes フラグを使用する場合は、以下を含める必要があります。Artifact Registry で使用する適切なアクセススコープ。

アクセススコープの設定

アクセススコープは、Compute Engine VM の認可を指定する以前の方法です。Artifact Registry リポジトリからイメージを pull するには、GKE ノードにストレージの読み取り専用アクセススコープまたはストレージの読み取りアクセスを含む別のストレージアクセススコープが必要です。

アクセススコープを設定できるのは、クラスタまたはノードプールの作成時のみです。既存のノードではアクセススコープを変更できません。

もし Compute Engine のデフォルトのサービスアカウントを使用している場合、GKE は Compute Engine デフォルトのアクセススコープを使用してノードを作成します。これにはストレージへの読み取り専用アクセスが含まれます。
ユーザー指定のサービスアカウントを使用している場合、GKE は cloud-platform スコープ（ほとんどの Google Cloud サービスに必要なスコープ）を持つノードを作成します。

クラスタの作成時にアクセススコープを指定するには、次のコマンドを実行します。

gcloud container clusters create NAME --scopes=SCOPES

ノードプールの作成時にアクセススコープを指定するには、次のコマンドを実行します。

gcloud container node-pools create NAME --scopes=SCOPES

次の値を置き換えます。

NAME は、クラスタまたはノードプールの名前です。
SCOPES は、付与するアクセススコープのカンマ区切りのリストです。
- Docker リポジトリにアクセスするには、次のいずれかのスコープを使用します。
- storage-ro - イメージの pull に対する読み取り専用権限を付与します。
- storage-rw - イメージを push または pull するための読み取りと書き込みの権限を付与します。
- cloud-platform - メタデータを含む Google Cloud サービス全体のデータを表示して管理します。
- 他のリポジトリにアクセスするには、cloud-platform スコープを使用する必要があります。
スコープの完全なリストについては、gcloud container clusters create または gcloud container node-pools create のドキュメントをご覧ください。

新しいクラスタの作成時に設定できるスコープの詳細については、gcloud container clusters create コマンドのドキュメントをご覧ください。

`imagePullSecret` の構成

imagePullSecret を構成するには:

GKE を含むプロジェクトで、Compute Engine のデフォルトのサービスアカウントを見つけます。アカウントのメールアドレスには、@developer.gserviceaccount.com というサフィックスが付加されています。
サービスアカウントのサービスアカウントキーをダウンロードします。

注: サービスアカウントキーが正しく管理されていない場合は、セキュリティリスクが発生します。可能であれば、サービスアカウントキーよりも安全な代替手段を選択してください。サービスアカウントキーで認証する必要がある場合は、秘密鍵のセキュリティと、サービスアカウントキーを管理するためのベストプラクティスで説明されているその他の操作は、ユーザーの責任で実施してください。サービスアカウントキーを作成できない場合は、組織でサービスアカウントキーの作成が無効になっている可能性があります。詳細については、デフォルトで安全な組織リソースの管理をご覧ください。
リポジトリを含むプロジェクトで、リポジトリに権限を付与済みであることを確認します。
クラスタを含むプロジェクトで、サービスアカウントキーを使用して artifact-registry と呼ばれる imagePullSecret シークレットを作成します。
```
kubectl create secret docker-registry artifact-registry \
--docker-server=https://LOCATION-docker.pkg.dev \
--docker-email=SERVICE-ACCOUNT-EMAIL \
--docker-username=_json_key \
--docker-password="$(cat KEY-FILE)"
```
次のように置き換えます。
- LOCATION は、リポジトリのリージョンまたはマルチリージョンのロケーションです。
- SERVICE-ACCOUNT-EMAIL は、Compute Engine サービスアカウントのメールアドレスです。
- KEY-FILE はサービスアカウントキーファイルの名前です。たとえば、key.json などです。
デフォルトのサービスアカウントを開きます。
```
kubectl edit serviceaccount default --namespace default
```
Kubernetes クラスタ内のすべての名前空間には、default というデフォルトのサービスアカウントがあります。このデフォルトサービスアカウントは、コンテナイメージを pull するために使用されます。

新しく作成した imagePullSecret シークレットをデフォルトのサービスアカウントに追加します。

imagePullSecrets:
- name: artifact-registry

サービスアカウントは次のようになります。

apiVersion: v1
kind: ServiceAccount
metadata:
  name: default
  namespace: default
  ...
secrets:
- name: default-token-zd84v
# The secret you created:
imagePullSecrets:
- name: artifact-registry

これで、現在の default 名前空間に作成された新しいポッドには、imagePullSecret シークレットが定義されます。

Artifact Registry サービスアカウント

Artifact Registry サービスエージェントは、Google Cloud サービスを操作するときに Artifact Registry の代理として動作する Google マネージドサービスアカウントです。このアカウントとその権限の詳細については、Artifact Registry サービスアカウントをご覧ください。

次のステップ

権限の設定後に、アーティファクトの操作に関する詳細を確認する。

コンテナイメージ: Docker、Helm
言語パッケージ: Java、Node.js、Python、Go
OS パッケージ: Debian、RPM

ダウンロードルールを使用してアーティファクトのダウンロードを制限することもできます。

IAM を使用したアクセス制御

始める前に

概要

Google Cloud のデフォルトの権限

サードパーティとの統合

Google Cloud での GitLab

ロールと権限

事前定義された Artifact Registry ロール

IAM の基本ロール

ロールを付与しています

プロジェクト全体のロールの付与

コンソール

gcloud

リポジトリ固有のロールの付与

コンソール

gcloud

Terraform

リポジトリへの公開アクセスを構成する

コンソール

gcloud

ロールを取り消し中

コンソール

gcloud

タグを使用した条件付きのアクセス権の付与

Google Cloud サービスとの統合

Google Cloud サービスのデフォルトのサービス アカウント

Compute Engine インスタンスへのアクセス権の付与

Google Kubernetes Engine クラスタへのアクセス権の付与

アクセス スコープの設定

imagePullSecret の構成

Artifact Registry サービス アカウント

次のステップ

Google Cloud サービスのデフォルトのサービスアカウント

アクセススコープの設定

`imagePullSecret` の構成

Artifact Registry サービスアカウント