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 許可ポリシーを分析します。

始める前に

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

2. Enable the Cloud Asset API.

   Enable the API

   既存の許可ポリシーを分析するプロジェクトまたは組織で API を有効にする必要があります。

3. 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 のロールの比較については、ロール マッピングをご覧ください。

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

1. マッピング ツールを実行します。

   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
   

2. このサービス アカウントは Artifact Registry リポジトリにアクセスする必要がないため、ポリシー ファイルから Container Registry サービス エージェントの行を削除します。サービス エージェントのメールアドレスの接尾辞は containerregistry.iam.gserviceaccount.com です。

   前の手順のポリシーの例では、Container Registry サービス エージェントを含む行は次のとおりです。

   - serviceAccount:service-1231231231231@containerregistry.iam.gserviceaccount.com
   

3. 他のロール バインディングを確認して、適切であることを確認します。

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

4. ポリシー ファイルにないプリンシパルのロール バインディングを追加します。

   返されたポリシー ファイルには、次のプリンシパルが欠落している可能性があります。

   • カスタムロールのあるプリンシパル。また、それらのカスタムロールには、ツールがロールのマッピングに使用した一連の権限がありません。
   • 親フォルダまたは組織を表示する権限がない場合、親フォルダまたは組織に対するアクセス権が付与されたプリンシパル。

5. ポリシー バインディングを 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 管理者