このドキュメントでは、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
リポジトリに手動で移行するか、pkg.dev
リポジトリに手動で移行します。Enable the Cloud Asset 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
のストレージ バケットを分析し、バケットに直接適用される許可ポリシー、または親組織 ID101231231231
とその子孫から継承される許可ポリシーについて調べます。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 管理者 |