Container Registry から Artifact Registry に IAM ロールをマッピングする

このドキュメントでは、Container Registry ロールを Artifact Registry ロールにマッピングし、Artifact Registry リポジトリに適用する方法について説明します。自動移行ツールを使用して同じ手順を完了できます。

Container Registry と Artifact Registry は、レジストリに保存されているコンテナイメージへのアクセスを制御するために、異なる Identity and Access Management（IAM）ロールを使用します。

Container Registry から Artifact Registry への移行を容易にするために、次の Google Cloud CLI コマンドを実行します。

Container Registry のイメージを格納する Cloud Storage ストレージバケットに適用される許可ポリシーを特定します。
既存の Container Registry ユーザーに Artifact Registry リポジトリへのアクセス権を付与できるように、同様の Artifact Registry ロールを持つポリシーを返します。

このコマンドは、IAM Policy Analyzer を使用して IAM 許可ポリシーを分析します。

始める前に

Artifact Registry リポジトリを作成する。移行に手動の方法を選択した場合は、手順に沿って Artifact Registry の gcr.io リポジトリに手動で移行するか、標準リポジトリに手動で移行します。
Enable the Cloud Asset API.
Enable the API

既存の許可ポリシーを分析するプロジェクトまたは組織で API を有効にする必要があります。
gcloud CLI をインストールして初期化します。既存のインストールの場合は、次のコマンドを使用して最新バージョンに更新します。
```
gcloud components update
```

必要なロール

許可ポリシーを分析して Artifact Registry リポジトリへのアクセス権を付与するために必要な権限を取得するには、アクセス許可を分析するプロジェクト、フォルダ、または組織に対して次の IAM ロールを付与するよう管理者に依頼してください。

Cloud Asset 閲覧者（roles/cloudasset.viewer）
カスタム IAM ロールでポリシーを分析するには: ロール閲覧者（roles/iam.roleViewer）
Google Cloud CLI を使用してポリシーを分析するには: Service Usage ユーザー（roles/serviceusage.serviceUsageConsumer）
Artifact Registry リポジトリにロールを付与するには: Artifact Registry 管理者

ロールの付与の詳細については、アクセス権の管理をご覧ください。

これらの事前定義ロールには、許可ポリシーを分析し、Artifact Registry リポジトリへのアクセス権を付与するために必要な権限が含まれています。必要とされる正確な権限については、「必要な権限」セクションを開いてご確認ください。

必要な権限

許可ポリシーを分析し、Artifact Registry リポジトリへのアクセス権を付与するには、次の権限が必要です。

cloudasset.assets.analyzeIamPolicy
cloudasset.assets.searchAllResources
cloudasset.assets.searchAllIamPolicies
IAM のカスタムロールでポリシーを分析するには: iam.roles.get
Google Cloud CLI を使用してポリシーを分析するには: serviceusage.services.use
Artifact Registry リポジトリにロールを付与するには: artifactregistry.repositories.setIamPolicy

カスタムロールや他の事前定義ロールを使用して、これらの権限を取得することもできます。

マッピングツールを使用する

マッピングツールは、指定された Container Registry ホスト名（gcr.io など）の許可ポリシーを確認します。

このツールは、事前定義された Cloud Storage ロールにある権限のセットを確認し、それらを Artifact Registry のロールにマッピングします。Cloud Storage の権限と Artifact Registry のロールの比較については、ロールマッピングをご覧ください。

ロールマッピングツールを使用するには：

マッピングツールを実行します。
```
gcloud beta artifacts docker upgrade print-iam-policy HOSTNAME \
    --project=PROJECT_ID > POLICY_FILENAME
```
次の値を置き換えます。
- HOSTNAME は、ツールで分析する Container Registry ホスト名です。
  - gcr.io
  - asia.gcr.io
  - eu.gcr.io
  - us.gcr.io
- PROJECT_ID は、分析するレジストリホストを含む Google Cloud プロジェクトの ID です。
- POLICY_FILE は、ツールが返すポリシーのファイル名（YAML 形式）です。
次のコマンドの例では、プロジェクト my-project 内の gcr.io のストレージバケットを分析し、バケットに直接適用される許可ポリシー、または親組織 ID 101231231231 とその子孫から継承される許可ポリシーについて調べます。
```
gcloud beta artifacts docker upgrade print-iam-policy gcr.io \
    --project=my-project > gcr-io-policy.yaml
```
このコマンドは、ストレージバケットの既存の許可ポリシーに基づいて、Artifact Registry ロールバインディングを含む YAML 形式のポリシーファイルを返します。ストレージバケットの親プロジェクトが組織にある場合、ポリシーファイルには、フォルダレベルまたは組織レベルでアクセス権が付与されたプリンシパルが含まれます。

たとえば、次のサンプルには、次の Artifact Registry ロールバインディングが含まれています。
- Cloud Build、Compute Engine、Container Registry のサービスエージェント。サービスエージェントは、Google Cloud サービスの代理として動作します。
- ユーザーアカウント user@example.com。
- ユーザー管理サービスアカウント deploy@my-project.iam.gserviceaccount.com。
```
bindings:
- members:
  - service-3213213213213@gcp-sa-cloudbuild.iam.gserviceaccount.com
  - user:user@example.com
  role: roles/artifactregistry.repoAdmin
- members:
  - serviceAccount:deploy@my-project.iam.gserviceaccount.com
  - serviceAccount:service-1231231231231@@compute-system.iam.gserviceaccount.com
  - serviceAccount:service-1231231231231@containerregistry.iam.gserviceaccount.com
  role: roles/artifactregistry.reader
```
このサービスアカウントは Artifact Registry リポジトリにアクセスする必要がないため、ポリシーファイルから Container Registry サービスエージェントの行を削除します。サービスエージェントのメールアドレスの接尾辞は containerregistry.iam.gserviceaccount.com です。

前の手順のポリシーの例では、Container Registry サービスエージェントを含む行は次のとおりです。
```
- serviceAccount:service-1231231231231@containerregistry.iam.gserviceaccount.com
```
他のロールバインディングを確認して、適切であることを確認します。

Artifact Registry には、一部のプリンシパルで考慮する必要がある追加の事前定義ロールがあります。たとえば、Artifact Registry の Create-on-push リポジトリ管理者は、Artifact Registry での gcr.io リポジトリの作成を許可し、他の Artifact Registry リポジトリの作成は許可されません。
ポリシーファイルにないプリンシパルのロールバインディングを追加します。

返されたポリシーファイルには、次のプリンシパルが欠落している可能性があります。
- カスタムロールのあるプリンシパル。また、それらのカスタムロールには、ツールがロールのマッピングに使用した一連の権限がありません。
- 親フォルダまたは組織を表示する権限がない場合、親フォルダまたは組織に対するアクセス権が付与されたプリンシパル。
ポリシーバインディングを Artifact Registry リポジトリに適用します。
```
gcloud artifacts repositories set-iam-policy REPOSITORY FILENAME \
    --project=PROJECT_ID \
    --location=LOCATION
```
次の値を置き換えます。
- REPOSITORY はリポジトリの名前です。
- POLICY_FILENAME は、リポジトリに適用するポリシーファイルの名前です。
- PROJECT_ID は、プロジェクト ID です。
- LOCATION は、リポジトリのリージョンまたはマルチリージョンのロケーションです。
プロジェクト my-project の例では、次の例で、ファイル gcr-io-policy.yaml 内のポリシーを、us マルチリージョンの gcr.io という名前のリポジトリに適用します。
```
gcloud artifacts repositories set-iam-policy gcr.io gcr-io-policy.yaml \
    --project=my-project \
    --location=us
```
上位レベルのリソースにロールバインディングを適用する場合は、追加するバインディングを使用して、既存のプロジェクト、フォルダ、または組織のポリシーを編集します。

ロールのマッピング

次の表に、既存の Container Registry ユーザーに付与する必要がある事前定義の Artifact Registry ロールを示します。これは、ユーザーが持つ Cloud Storage の権限によって異なります。

ロールに必要な権限	Artifact Registry ロール
`storage.objects.get` `storage.objects.list`	Artifact Registry 読み取り
`storage.buckets.get` `storage.objects.get` `storage.objects.list` `storage.objects.create`	Artifact Registry 書き込み
`storage.buckets.get` `storage.objects.get` `storage.objects.list` `storage.objects.create` `storage.objects.delete`	Artifact Registry リポジトリ管理者
`storage.buckets.get` `storage.objects.get` `storage.objects.list` `storage.objects.create` `storage.buckets.create`	Artifact Registry 管理者