ロールと権限を構成する

このページでは、Artifact Registry リポジトリへの権限の付与について説明します。

始める前に

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

概要

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

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

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

サードパーティとの統合

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

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

ロールと権限

権限を含むロールを付与することで、Identity and Access Management（IAM）権限を付与します。プロジェクトレベルまたはリポジトリレベルで権限を付与できます。

Artifact Registry の事前定義ロール

IAM には事前定義ロールが用意されています。こうしたロールを使用すると、特定の Google Cloud リソースに対するアクセス権を付与し、それ以外のリソースへの無認可のアクセスを防止できます。

Artifact Registry では、次の事前定義されたロールを使用できます。

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

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

IAM の基本ロール

IAM の基本ロールは、すべての Google Cloud リソースへのグローバルなプロジェクトレベルのアクセス権をユーザーに付与します。ユーザーとサービスアカウントに必要な権限のみが含まれるように、可能な限り事前定義ロールを使用してリポジトリにアクセスできるようにします。

次の表に、IAM のリリース前に存在していた基本ロールと、基本ロールに含まれる Artifact Registry の IAM ロールの一覧を示します。

役割	役割のタイトル	含まれるロール
`roles/viewer`	閲覧者	`roles/artifactregistry.reader`
`roles/editor`	編集者	`roles/artifactregistry.writer` `roles/artifactregistry.repoAdmin`
`roles/owner`	Owner	`roles/artifactregistry.admin`

権限の付与

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

gcloud コマンドを使用してロールを付与する場合は、プリンシパルに対して 1 つのロールバインディングを指定するか、ポリシーファイルを使用して複数のバインディングを定義します。

このページの例では、次の参照ポリシーテンプレートを使用しています。参照ポリシーファイルの名前は policy.yaml です。テンプレートには、ユーザー名とサービスアカウント名の例が含まれています。以下のサンプルのユーザーとサービスアカウントをプロジェクトに合わせて置き換えてください。

ポリシーの形式の詳細については、IAM ポリシーのドキュメントをご覧ください。

bindings:

- members:
  - user: user@gmail.com
  role: roles/owner

- members:
  - serviceAccount: repo-readonly@iam.gserviceaccount.com
  - user: user2@gmail.com
  role: roles/artifactregistry.reader

- members:
  - serviceAccount: repo-write@iam.gserviceaccount.com
  role: roles/artifactregistry.writer

- members:
  - serviceAccount: repo-admin@iam.gserviceaccount.com
  role: roles/artifactregistry.repoAdmin

- members:
  - serviceAccount: ar-admin@iam.gserviceaccount.com
  role: roles/artifactregistry.admin

プロジェクト全体の権限の付与

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

チームメンバーをプロジェクトに追加し、Artifact Registry のロールを付与するには:

コンソール

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

gcloud

Google Cloud コンソールで、「Cloud Shell をアクティブにする」をクリックします。

Cloud Shell をアクティブにする

Google Cloud コンソールの下部で Cloud Shell セッションが開始し、コマンドラインプロンプトが表示されます。Cloud Shell はシェル環境です。Google Cloud CLI がすでにインストールされており、現在のプロジェクトの値もすでに設定されています。セッションが初期化されるまで数秒かかることがあります。
単一のプリンシパルにロールを付与するには、次のコマンドを実行します。
```
gcloud projects add-iam-policy-binding PROJECT \
   --member=PRINCPAL \
   --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 のドキュメントをご覧ください。

ポリシーファイルを使用してロールを付与するには、次のコマンドを実行します。
```
gcloud projects set-iam-policy PROJECT /PATH/TO/policy.yaml
```
ここで
- PROJECT は、Artifact Registry が実行されているプロジェクトの ID または完全修飾識別子です。
- /PATH/TO/policy.yaml は、ポリシーファイルのパスとファイル名です。
現在構成されているポリシーを取得するには、次のコマンドを実行します。
```
gcloud projects get-iam-policy PROJECT
```
PROJECT はプロジェクトの ID またはプロジェクトの完全修飾識別子です。

詳細については、set-iam-policy のドキュメントをご覧ください。

リポジトリに固有の権限の付与

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

コンソール

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

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

[リポジトリ] ページを開く
適切なリポジトリを選択します。
情報パネルが表示されない場合は、メニューバーの [情報パネルを表示] をクリックします。
[権限] タブで、[プリンシパルを追加] をクリックします。
メールアドレスを入力します。個人、サービスアカウント、Google グループをプリンシパルとして追加できます。
プリンシパルのロールを選択します。プリンシパルに付与する権限は最小限の権限に留めることを推奨します。
[保存] をクリックします。

gcloud

Google Cloud コンソールで、「Cloud Shell をアクティブにする」をクリックします。

Cloud Shell をアクティブにする

Google Cloud コンソールの下部で Cloud Shell セッションが開始し、コマンドラインプロンプトが表示されます。Cloud Shell はシェル環境です。Google Cloud CLI がすでにインストールされており、現在のプロジェクトの値もすでに設定されています。セッションが初期化されるまで数秒かかることがあります。
個別のポリシーバインディングの 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-central1 のリポジトリ my-repo を持つ IAM ポリシーバインディングを追加するには、次のコマンドを実行します。
```
gcloud artifacts repositories add-iam-policy-binding my-repo \
--location=us-central1 --member=user:write@gmail.com --role=roles/artifactregistry.writer
```
ポリシーファイルを使用してロールを付与するには、次のコマンドを実行します。
```
gcloud artifacts repositories set-iam-policy REPOSITORY /PATH/TO/policy.yaml --location=LOCATION
```
ここで
- REPOSITORY はリポジトリの ID です。
- /PATH/TO/policy.yaml は、ポリシーファイルのパスとファイル名です。
- LOCATION は、リポジトリのリージョンまたはマルチリージョンのロケーションです。
たとえば、policy.yaml で定義されたポリシーを使用して、ロケーション --us-central1 のリポジトリ my-repo の IAM ポリシーを設定するには、次のコマンドを実行します。
```
gcloud artifacts repositories set-iam-policy my-repo policy.yaml --location=us-central1
```

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

Google Cloud コンソールで、「Cloud Shell をアクティブにする」をクリックします。

Cloud Shell をアクティブにする

Google Cloud コンソールの下部で Cloud Shell セッションが開始し、コマンドラインプロンプトが表示されます。Cloud Shell はシェル環境です。Google Cloud CLI がすでにインストールされており、現在のプロジェクトの値もすでに設定されています。セッションが初期化されるまで数秒かかることがあります。
次のコマンドを実行します。
```
gcloud artifacts repositories add-iam-policy-binding REPOSITORY \
--location=LOCATION --member=allUsers --role=ROLE
```
ここで
- REPOSITORY はリポジトリの ID です。
- ROLE は、付与するロールです。
- LOCATION は、リポジトリのリージョンまたはマルチリージョンのロケーションです。
たとえば、ロケーション --us-central1 のリポジトリ my-repo を一般公開として構成するには、次のコマンドを実行します。
```
gcloud artifacts repositories add-iam-policy-binding my-repo \
 --location=us-central1 --member=allUsers --role=roles/artifactregistry.reader
```
未認証のユーザーによる誤使用を防ぐために、Artifact Registry API リクエストにユーザーごとの制限を設定します。手順については、使用量の上限を設定するをご覧ください。

権限の取り消し

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

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

コンソール

権限を取り消すには:

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

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

gcloud

Google Cloud コンソールで、「Cloud Shell をアクティブにする」をクリックします。

Cloud Shell をアクティブにする

Google Cloud コンソールの下部で Cloud Shell セッションが開始し、コマンドラインプロンプトが表示されます。Cloud Shell はシェル環境です。Google Cloud CLI がすでにインストールされており、現在のプロジェクトの値もすでに設定されています。セッションが初期化されるまで数秒かかることがあります。
プロジェクトレベルでロールを取り消すには、次のコマンドを実行します。
```
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
   --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-central1 ロケーションのリポジトリ my-repo を持つユーザー write@gmail.com のロール roles/artifactregistry.writer のポリシーバインディングを削除するには、次のコマンドを実行します。
```
gcloud artifacts repositories remove-policy-binding my-repo \
   --location=us-central1 \
   --member=user:write@gmail.com \
   --role=roles/artifactregistry.writer
```
ロケーション --us-central1 にある my-repo への公開アクセスを取り消すには、次のコマンドを実行します。
```
gcloud artifacts repositories remove-policy-binding my-repo \
   --location=us-central1 \
   --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 が管理するサービスアカウントを使用して、同じプロジェクト内のリソースを操作します。

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

Google Cloud サービスが Artifact Registry とは異なるプロジェクトにある。
デフォルトの権限ではニーズが満たされない。たとえば、デフォルトの Compute Engine サービスアカウントには、同じプロジェクトのストレージに対する読み取り専用アクセス権が付与されます。VM から Artifact Registry にイメージを push する場合は、VM サービスアカウントの権限を変更するか、必要な権限を持つ別のアカウントを使用します。
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	Cloud Build サービスアカウント	`PROJECT-NUMBER`@cloudbuild.gserviceaccount.com	デフォルトの権限には、リポジトリへの読み書きアクセス権が含まれます。
Cloud Run	Compute Engine のデフォルトのサービスアカウントリビジョンに対するデフォルトのランタイムサービスアカウント。	`PROJECT-NUMBER`-compute@developer.gserviceaccount.com	編集者ロール（リポジトリの読み取り専用アクセスに限定）
GKE	Compute Engine のデフォルトのサービスアカウントノードのデフォルトのサービスアカウント。	`PROJECT-NUMBER`-compute@developer.gserviceaccount.com	編集者ロール（リポジトリの読み取り専用アクセスに限定）

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 を使用していない場合は、imagePullSecret を構成します。

ユーザー指定のサービスアカウント

ユーザー指定のサービスアカウントをクラスタの 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 Secret を作成します。
```
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
OS パッケージ: Debian、RPM

ロールと権限を構成する

始める前に

概要

Google Cloud との統合

サードパーティとの統合

ロールと権限

Artifact Registry の事前定義ロール

IAM の基本ロール

権限の付与

プロジェクト全体の権限の付与

コンソール

gcloud

リポジトリに固有の権限の付与

コンソール

gcloud

Terraform

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

コンソール

gcloud

権限の取り消し

コンソール

gcloud

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

Google Cloud サービスとの統合

Google Cloud サービスのデフォルトの権限

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

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

アクセス スコープの設定

imagePullSecret の構成

Artifact Registry サービス アカウント

次のステップ

アクセススコープの設定

Artifact Registry サービスアカウント