Artifact Registry でデフォルトでホストされている gcr.io

Artifact Registry で gcr.io リポジトリを設定する方法、Artifact Registry と Container Registry の権限とストレージ バケットの構成の違いについて学びます。

このドキュメントで説明する手動の手順は、自動移行ツールを使用して実行できます。自動移行ツールを使用して、Container Registry をアクティブに使用しているプロジェクトを Artifact Registry の標準リポジトリまたは gcr.io リポジトリに移行する場合は、Artifact Registry への移行の自動化をご覧ください。

Container Registry のサポート終了

2024 年 5 月 15 日以前に Container Registry を使用したことがない Google Cloud プロジェクトでは、Artifact Registry でのイメージのホスティングと管理のみがサポートされます。この変更による影響は次のとおりです。

  • 新しく作成されたプロジェクト。
  • Container Registry にイメージを push したことがない既存のプロジェクト。

2024 年 1 月 8 日より前に Container Registry を使用していない組織では、デフォルトで Artifact Registry に新しい gcr.io リポジトリがホストされます。

これらのプロジェクトで Artifact Registry API を有効にすると、Artifact Registry は Artifact Registry での gcr.io リポジトリの作成を自動的に処理し、gcr.io ドメインへのリクエストを適切な Artifact Registry リポジトリにリダイレクトします。Container Registry がアクティブに使用されているプロジェクトの既存の gcr.io ドメイン サポートとは異なり、Artifact Registry へのリダイレクトは自動的に行われます。

Container Registry は、2024 年 5 月 15 日より前に次のいずれかのアクションが行われたプロジェクトでは引き続き使用できます。

  • プロジェクトで Container Registry API を有効にしている。
  • イメージをプロジェクト内のレジストリ ホストに push した。

今後の変更に備えて、以下を行うことをおすすめします。

  • このドキュメントの手順に沿って、Container Registry を使用していないプロジェクトを構成し、変更が有効になったときに gcr.io リクエストの自動処理を準備するようにします。
  • gcr.io ドメイン サポートをテストして、既存の自動化が引き続き機能することを確認します。

Artifact Registry でホストされている gcr.io リポジトリは、Container Registry がサポートする同じマルチリージョンに作成されます。他のリージョンにイメージを保存する場合は、pkg.dev ドメインの標準リポジトリに移行する必要があります。

必要なロール

gcr.io リポジトリの設定に必要な権限を取得するには、管理者に次の IAM ロールを付与するよう依頼してください。

  • Artifact Registry リポジトリを作成し、個々のリポジトリへのアクセス権を付与する: プロジェクトの Artifact Registry 管理者（roles/artifactregistry.admin）
  • Cloud Storage ストレージ バケットに適用される既存の Container Registry 構成を表示して管理する: プロジェクトのストレージ管理者（roles/storage.admin）
  • プロジェクト レベルでリポジトリへのアクセス権を付与する: プロジェクト IAM 管理者（roles/resourcemanager.projectIamAdmin）、またはプロジェクト、フォルダ、組織のフォルダ管理者（roles/resourcemanager.folderAdmin）や組織管理者（roles/resourcemanager.organizationAdmin）などの同等の権限を含むロール
  • 組織内の有効なサービスを一覧表示する: 組織の Cloud Asset 閲覧者（roles/cloudasset.viewer）

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

必要な権限は、カスタムロールや他の事前定義ロールから取得することもできます。

準備

Container Registry に 1 つ以上のイメージが保存されているプロジェクトを一覧表示できます。そうするとで、このドキュメントの手順に沿って、Artifact Registry で gcr.io リクエストをホストするための他のプロジェクトの設定に集中できます。

次のコマンドを実行して、Google Cloud 組織内の Container Registry の使用状況を確認します。

  gcloud container images list-gcr-usage \
      --organization=ORGANIZATION

ORGANIZATION を Google Cloud 組織 ID に置き換えます。

プロジェクトまたはフォルダの Container Registry の使用状況を一覧表示することもできます。Container Registry の使用状況を確認する方法については、Container Registry の使用状況を確認するをご覧ください。

API を有効にする

Artifact Registry API を有効にして、自動 gcr.io ホスティングが有効になったときに gcr.io ドメインへのリクエストが Artifact Registry によって自動的に処理されるようにします。

  1. 次のコマンドを実行します。

    gcloud services enable \
    artifactregistry.googleapis.com

  2. 通常、Container Registry API を VPC Service Controls サービス境界に配置する場合は、Artifact Registry API も境界内に配置してください。手順については、サービス境界でのリポジトリの保護をご覧ください。

リポジトリに権限を付与する

Container Registry では、Cloud Storage のロールを使用してアクセスを制御します。Artifact Registry には独自の IAM ロールがあり、これらのロールは読み取り、書き込み、リポジトリ管理のロールを Container Registry よりも明確に分離しています。

ストレージ バケットに付与されている既存の権限を、推奨される Artifact Registry のロールにすばやくマッピングするには、ロール マッピング ツールを使用します。

また、Google Cloud コンソールを使用して、ストレージ バケットにアクセスできるプリンシパルのリストを表示することもできます。

  1. Google Cloud コンソールで、Cloud Storage の [バケット] ページに移動します。

    [バケット] に移動

  2. 表示するレジストリ ホストのストレージ バケットをクリックします。バケット名で、PROJECT-ID は Google Cloud プロジェクト ID です。

    • gcr.io: artifacts.PROJECT-ID.appspot.com
    • asia.gcr.io: asia.artifacts.PROJECT-ID.appspot.com
    • eu.gcr.io: eu.artifacts.PROJECT-ID.appspot.com
    • us.gcr.io: us.artifacts.PROJECT-ID.appspot.com

  3. [権限] タブをクリックします。

  4. [Permissions] タブで、[View by role] サブタブをクリックします。

  5. ロールを開いて、そのロールを持つプリンシパルを表示します。

リストには、バケットに直接付与された IAM ロールと、親プロジェクトから継承されたロールが含まれます。ロールに基づいて、最適な Artifact Registry のロールを選択して付与できます。

Cloud Storage と基本ロール

現在 Container Registry にアクセスしているユーザーとサービス アカウントに、Artifact Registry リポジトリへのアクセス権を付与します。親プロジェクトから継承された Cloud Storage のロールについては、プリンシパルが現在 Container Registry を使用していることを確認する必要があります。一部のプリンシパルは、Container Registry に関係のない他の Cloud Storage バケットにのみアクセスできる場合があります。

IAM の導入前から存在する基本ロールのオーナー、編集者、閲覧者は、ストレージ バケットへのアクセスが制限されています。それらのロールは本質的に名前が示すように Cloud Storage リソースに対するすべてのアクセス権を付与するものではなく、その他の Google Cloud サービスに対する追加の権限を付与します。Artifact Registry にアクセスする必要があるユーザーとサービス アカウントを確認します。ロールのマッピングの表を使用して、Artifact Registry へのアクセスが妥当である場合に、適切なロールを付与できます。

次の表に、Container Registry へのアクセス用に事前定義された Cloud Storage ロールによって付与される権限に基づいて、Artifact Registry のロールを示します。

必要なアクセス権 現在のロール Artifact Registry のロール ロールを付与する場所
イメージの pull のみ（読み取り専用） Storage オブジェクト閲覧者
（roles/storage.objectViewer）		 Artifact Registry 読み取り
（roles/artifactregistry.reader)）		 Artifact Registry リポジトリまたは Google Cloud プロジェクト
  • イメージの push と pull（読み取りと書き込み）
  • 画像の削除
 Storage レガシー バケット書き込み
（roles/storage.legacyBucketWriter）		 Artifact Registry リポジトリ管理者
（roles/artifactregistry.repoAdmin)）		 Artifact Registry リポジトリまたは Google Cloud プロジェクト
プロジェクトでイメージが gcr.io ホスト名に初めて push されたときに、Artifact Registry で gcr.io リポジトリを作成する。 ストレージ管理者
（roles/storage.admin）		 Artifact Registry の Create-on-push リポジトリ管理者
(roles/artifactregistry.createOnPushRepoAdmin)		 Google Cloud プロジェクト
リポジトリの作成、管理、削除 ストレージ管理者
（roles/storage.admin）		 Artifact Registry 管理者
(roles/artifactregistry.Admin)		 Google Cloud プロジェクト
プロジェクトから継承されたサービス エージェントのロール

Google Cloud サービスのデフォルトのサービス アカウントには、プロジェクト レベルで独自のロールが付与されています。たとえば、Cloud Run のサービス エージェントには Cloud Run サービス エージェントのロールがあります。

ほとんどの場合、これらのサービス エージェントのロールには Container Registry と Artifact Registry に対する同等のデフォルト権限が含まれています。既存の Container Registry サービスと同じプロジェクトで Artifact Registry を実行している場合は、追加の変更は必要ありません。

サービス エージェントのロールの権限について詳しくは、サービス エージェントのロールのリファレンスをご覧ください。

カスタムロール

ロールのマッピングの表を使用して、必要なアクセスレベルに基づいてユーザーまたはサービス アカウントに付与するロールを決定できます。

Artifact Registry のロールを付与する手順については、ロールと権限を構成するをご覧ください。

ストレージ バケットの構成

Artifact Registry でリポジトリを作成すると、Artifact Registry はプロジェクトに対応する Cloud Storage バケットを作成しません。ストレージ バケットと直接やり取りする Container Registry を自動化している場合は、Artifact Registry リポジトリに対応する変更を行うように Container Registry を更新する必要があります。

たとえば、Container Registry のストレージ バケットに対する Cloud Storage 権限をプログラムで付与する場合は、gcr.io ドメインのイメージをホストする Artifact Registry リポジトリに対して Artifact Registry 権限を付与するように、その自動化を更新する必要があります。

Artifact Registry では、ストレージ バケットではなくリポジトリに保存するデータの暗号化方法を設定します。Artifact Registry での自動 gcr.io ホスティングは、Google が管理する暗号鍵で暗号化された gcr.io リポジトリを作成します。顧客管理の暗号鍵（CMEK）を使用する場合は、gcr.io リポジトリを自分で作成し、作成時に暗号化方法として CMEK を指定する必要があります。

gcr.io リポジトリを手動で作成するには、次のコマンドを実行します。

  1. CMEK を使用している場合は、このリポジトリで使用する鍵を作成し、その鍵を使用する権限を付与します。顧客管理の暗号鍵の有効化をご覧ください。

  2. リポジトリを追加します。

    コンソール

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

      [リポジトリ] ページを開く

    2. [リポジトリを作成] をクリックします。

    3. リポジトリ名を指定します。

      Container Registry ホスト名 Artifact Registry リポジトリ名
      gcr.io gcr.io
      asia.gcr.io asia.gcr.io
      eu.gcr.io eu.gcr.io
      us.gcr.io us.gcr.io

    4. Docker をリポジトリ形式として指定します。

    5. [ロケーション タイプ] で、リポジトリのマルチリージョンを指定します。

      Container Registry ホスト名 Artifact Registry リポジトリのロケーション
      gcr.io us
      asia.gcr.io asia
      eu.gcr.io europe
      us.gcr.io us

    6. リポジトリの説明を追加します。リポジトリの説明は暗号化されないため、機密データは含めないでください。

    7. [暗号化] セクションで、リポジトリの暗号化方式を選択します。

      • Google が管理する鍵 - Google が管理する暗号鍵を使用してリポジトリのコンテンツを暗号化します。
      • 顧客管理の暗号鍵 - Cloud Key Management Service で管理する鍵を使用してリポジトリのコンテンツを暗号化します。鍵の設定手順については、リポジトリの CMEK の設定をご覧ください。

    8. [作成] をクリックします。

    gcloud

    次のコマンドを実行して新しいリポジトリを作成します。

    gcloud artifacts repositories create REPOSITORY \
    --repository-format=docker \
    --location=LOCATION \
    --description=DESCRIPTION \
    --kms-key=KMS-KEY

    次の値を置き換えます。

    • REPOSITORY はリポジトリの名前です。

      Container Registry ホスト名 Artifact Registry リポジトリ名
      gcr.io gcr.io
      asia.gcr.io asia.gcr.io
      eu.gcr.io eu.gcr.io
      us.gcr.io us.gcr.io

    • LOCATION は、リポジトリのマルチリージョンです。

      Container Registry ホスト名 Artifact Registry リポジトリのロケーション
      gcr.io us
      asia.gcr.io asia
      eu.gcr.io europe
      us.gcr.io us

    • DESCRIPTION はリポジトリの説明です。リポジトリの説明は暗号化されないため、機密データは含めないでください。

    • KMS-KEY は、リポジトリのコンテンツを暗号化するために顧客管理の暗号鍵を使用する場合、Cloud KMS 暗号鍵のフルパスです。パスの形式は次のとおりです。

      projects/KMS-PROJECT/locations/KMS-LOCATION/keyRings/KEY-RING/cryptoKeys/KEY

      次の値を置き換えます。

      • KMS-PROJECT は、鍵が保存されているプロジェクトです。
      • KMS-LOCATION は鍵の場所です。
      • KEY-RING はキーリングの名前です。
      • KEY は、鍵の名前です。

    次のコマンドでリポジトリを一覧表示することで、リポジトリが作成されたことを確認できます。

    gcloud artifacts repositories list

次のステップ

テスト プロジェクトでgcr.io ドメイン サポートを設定し、Cloud Build、Google Kubernetes Engine、Cloud Functions などの既存の自動化やサービスとの統合が期待通りに機能するかを検証します。