IAM を使用したアクセス制御

このページでは、Container Registry へのアクセスを制御する権限について説明します。

権限を構成したら、イメージの push や pull に使用する Docker クライアントの認証を構成できます。

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

始める前に

ユーザー管理の権限があることを確認します。次のいずれかのロールの権限が必要です。

  • Project IAM 管理者（roles/resourcemanager.projectIamAdmin）
  • セキュリティ管理者（roles/iam.securityAdmin）

これらのロールを付与する代わりに、同じ権限を持つカスタムロールや事前定義ロールも使用できます。

権限と役割

Container Registry を操作するユーザー、サービス アカウントなどの ID のすべてには、Cloud Storage に対する適切な Identity and Access Management（IAM）権限が必要です。

  • 通常、Container Registry にアクセスする Google Cloud サービスには、同じ Google Cloud プロジェクト内のレジストリに対するデフォルトの権限が構成されます。デフォルトの権限がニーズに合わない場合は、適切な権限を構成する必要があります。
  • 他の ID については、必要な権限を構成する必要があります。

Container Registry ホストへのアクセス権は、Cloud Storage の権限で制御します。次の表では、Container Registry が必要とする権限を持つ Cloud Storage のロールを示します。

Google Cloud Console を使用して Container Registry イメージを表示する場合は、いくつかの追加権限が必要です。Cloud Console の使用に必要な共通の権限をご覧ください。

必要なアクセス権 ロール 付与する権限の対象
既存のレジストリからイメージを pull する（読み取り専用） Storage オブジェクト閲覧者（roles/storage.objectViewer） レジストリ ストレージ バケットに対するロールを付与します。
プロジェクト内の既存のレジストリ ホストに対してイメージを push（書き込み）および pull（読み取り）する Storage レガシー バケット書き込み（roles/storage.legacyBucketWriter） レジストリ ストレージ バケットに対するロールを付与します。この権限はバケットレベルでのみ利用でき、プロジェクト レベルでは付与できません。
Google Cloud プロジェクトにレジストリ ホストを追加し、関連するストレージ バケットを作成します。 ストレージ管理者（roles/storage.admin） プロジェクト レベルでロールを付与します。

イメージを push するには、storage.buckets.get 権限に加え、オブジェクトの読み取り権限と書き込み権限が必要です。Storage レガシー バケット書き込みロールには、単一の Cloud Storage ロールに必要な権限が付与されていますが、ストレージ バケットとオブジェクトを完全に制御することはできません。

ストレージ管理者のロールは、ストレージ バケットとオブジェクトに対する完全な制御権を付与します。この権限をプロジェクト レベルで付与すると、プリンシパルは、Container Registry で使用されていないバケットを含む、プロジェクト内のすべてのストレージ バケットにアクセスできるようになります。このロールを必要とするプリンシパルは、慎重に検討してください。

  • デフォルトでは、Cloud Build サービス アカウントには、ストレージ管理者ロールの権限が付与されています。したがって、このサービス アカウントでは、最初の push で親プロジェクトにレジストリを追加して、親プロジェクトの既存のレジストリにイメージを push できます。
  • Docker などのツールを使用してイメージを作成し、レジストリに push する場合は、より大きなストレージ管理者ロールを持つアカウントを使用してレジストリをプロジェクトに追加し、Storage レガシー バケット書き込みロールや Storage オブジェクト閲覧者ロールを、イメージの push や pull を行う必要がある他のアカウントに付与することを検討してください。

Cloud Storage のロールと権限の詳細については、Cloud Storage のドキュメントをご覧ください。

IAM 権限を付与する

Container Registry は、コンテナ イメージの基盤となるストレージとして Cloud Storage バケットを使用します。イメージへのアクセス権は、レジストリ用のバケットに権限を付与することによって制御します。

ホスト名に push した最初のイメージでは、レジストリ ホストとストレージ バケットをプロジェクトに追加します。たとえば、gcr.io/my-project への最初の push にって、gcr.io レジストリ ホストが my-project のプロジェクト ID を持つプロジェクトに追加され、レジストリ用のストレージ バケットが作成されます。バケット名の形式は、次のいずれかになります。

  • artifacts.PROJECT-ID.appspot.com（イメージがホスト gcr.io に保存されている場合）
  • STORAGE-REGION.artifacts.PROJECT-ID.appspot.com（イメージが他のレジストリ ホストに保存されている場合）

この最初のイメージの push を正常に行うには、push を実行するアカウントに、ストレージ管理者ロールの権限が必要です。

レジストリ ホストに最初のイメージの push を行った後は、レジストリ ストレージ バケットに権限を付与し、レジストリ内のイメージへのアクセスを制御します。

  • Storage レガシー バケット書き込み（push と pull）
  • Storage オブジェクト閲覧者（pull のみ）

Google Cloud コンソール または Google Cloud CLI を使用して、バケットの権限を付与できます。

制限事項

Container Registry ホストに対しては、ストレージ バケットレベルでのみ権限を付与できます。

  • Container Registry では、Cloud Storage バケット内の個々のオブジェクトに設定された権限が無視されます。
  • レジストリ内のリポジトリには、権限を付与できません。より細かいアクセス制御が必要な場合は、Artifact Registry がリポジトリ レベルのアクセス制御を提供しており、よりニーズに適しているかもしれません。
  • どの Container Registry ストレージ バケットに対しても均一なバケットレベルのアクセスを有効にする場合は、レジストリにアクセスするすべてのユーザーとサービス アカウントに権限を明示的に付与する必要があります。この場合、オーナーロールと編集者ロールで必要な権限が付与されないことがあります。

権限を付与する

  1. レジストリ ホストがプロジェクトにまだ存在しない場合は、ストレージ管理者のロールの権限を持つアカウントで最初のイメージをレジストリに push する必要があります。これにより、レジストリ ホストのストレージ バケットが作成されます。

    Cloud Build には、同じプロジェクト内で最初のイメージの push を実行するために必要な権限があります。別のツールでイメージを push する場合は、Container Registry で認証に使用している Google Cloud アカウントの権限を確認します。

    Docker を使用して最初のイメージを push する方法の詳細については、レジストリの追加をご覧ください。

  2. Container Registry を使用するプロジェクトで、レジストリ ホストにより使用される Cloud Storage バケットに適切な権限を付与します。

    コンソール

    1. Google Cloud コンソールの [Cloud Storage] ページに移動します。

    2. バケットのリンク artifacts.PROJECT-ID.appspot.com または STORAGE-REGION.artifacts.PROJECT-ID.appspot.com をクリックします。

      PROJECT-ID は、Container Registry をホストしているプロジェクトの Google Cloud プロジェクト ID に置き換えます。STORAGE-REGION は、イメージをホストするレジストリのマルチリージョン（asia、eu、または us）に置き換えます。

    3. [権限] タブを選択します。

    4. [追加] をクリックします。

    5. [プリンシパル] フィールドに、アクセス権が必要なアカウントのメールアドレスをカンマで区切って入力します。このメールアドレスは、次のいずれかになります。

      • Google アカウント（例: someone@example.com）
      • Google グループ（例: my-developer-team@googlegroups.com）

      • IAM サービス アカウント

        いつも決まってレジストリにアクセスする Google Cloud サービスのリストを確認して、関連するサービス アカウントのメールアドレスを見つけます。そのサービスが Container Registry とは異なるプロジェクトで実行されている場合は、他のプロジェクトでそのサービス アカウントのメールアドレスを使用していることを確認してください。

    6. [ロールを選択] プルダウン メニューから [Cloud Storage] カテゴリを選択し、つづいて適切な権限を選択します。

      • Storage Object Viewer。イメージのみを pull する場合。
      • Storage レガシー バケット書き込み。イメージを push および pull する場合。

    7. [追加] をクリックします。

    gcloud

    1. 次のコマンドを実行して、プロジェクト内のバケットを一覧表示します。

      gcloud storage ls

      次の例のようなレスポンスになります。

      gs://[BUCKET_NAME1]/
gs://[BUCKET_NAME2]/
gs://[BUCKET_NAME3]/ ...

      返されたバケットリストで、レジストリ ホストのバケットを見つけます。イメージを保存するバケットは、次のいずれかの形式の名前 BUCKET-NAME を持っています。

      • artifacts.PROJECT-ID.appspot.com（イメージがホスト gcr.io に保存されている場合）
      • STORAGE-REGION.artifacts.PROJECT-ID.appspot.com（イメージが他のレジストリ ホストに保存されている場合）

      ここで

      • PROJECT-ID は、Google Cloud プロジェクト ID です。
      • STORAGE-REGION は、ストレージ バケットの場所です。
        • us。us.gcr.io ホストのレジストリの場合
        • eu: eu.gcr.io ホストのレジストリの場合
        • asia。asia.gcr.io ホストのレジストリの場合

    2. シェルまたはターミナル ウィンドウで次のコマンドを実行します。

      gcloud storage buckets add-iam-policy-binding gs://BUCKET_NAME \
--member=TYPE:EMAIL-ADDRESS \
--role=ROLE

      ここで

      • BUCKET_NAME は、artifacts.PROJECT-ID.appspot.com または STORAGE-REGION.artifacts.PROJECT-ID.appspot.com の形式の Cloud Storage バケットの名前です。
      • TYPE は、以下のいずれかになります。
        • serviceAccount。EMAIL-ADDRESS がサービス アカウントを指定している場合。
        • user。EMAIL-ADDRESS が Google アカウントの場合。
        • group。EMAIL-ADDRESS が Google グループの場合。

      • EMAIL-ADDRESS は、以下のいずれかになります。

        • Google アカウント（例: someone@example.com）
        • Google グループ（例: my-developer-team@googlegroups.com）

        • IAM サービス アカウント

          いつも決まってレジストリにアクセスする Google Cloud サービスのリストを確認して、関連するサービス アカウントのメールアドレスを見つけます。そのサービスが Container Registry とは異なるプロジェクトで実行されている場合は、他のプロジェクトでそのサービス アカウントのメールアドレスを使用していることを確認してください。

      • ROLE は、付与する Cloud Storage のロールです。

        • objectViewer。イメージを pull する場合。
        • legacyBucketWriter。イメージを push および pull する場合。

    たとえば、次のコマンドは、バケット my-example-bucket 内のイメージを push および pull する権限をサービス アカウント my-account@my-project.iam.gserviceaccount.com に付与します。

    gcloud storage buckets add-iam-policy-binding gs://my-example-bucket \
  --member=serviceAccount:my-account@my-project.iam.gserviceaccount.com \
  --role=roles/storage.objectUser

    gcloud storage buckets add-iam-policy-binding コマンドは、レジストリがホストされているストレージ バケットの IAM 権限を変更します。他の例については、gcloud CLI のドキュメントをご覧ください。

  3. イメージを Container Registry に push する Compute Engine VM や GKE ノードへのアクセスを構成する場合は、VM とクラスタの構成で追加の構成手順をご覧ください。

イメージへの公開アクセス権を構成する

Container Registry は、ホストの場所の基になるストレージ バケットが公開アクセス可能であれば、公開アクセス可能です。プロジェクト内では、各ホストの場所のイメージがすべて公開されるか、すべて公開されないかのいずれかになります。プロジェクトのホスト内で、特定のイメージのみを公開することはできません。公開したい特定のイメージがある場合:

  • 公開用の別のホストの場所に保管する
  • 公開アクセス可能なイメージを保存するための新しいプロジェクトを作成する

コンテナ イメージを一般公開するには、次の手順で基盤となるストレージバケットを一般公開します。

  1. イメージを Container Registry に push し、基になるストレージ バケットが存在していることを確認します。

  2. そのレジストリの Cloud Storage バケットの名前を確認します。これを行うには、バケットを一覧表示します。

    gcloud storage ls

    Container Registry バケット URL は、gs://artifacts.PROJECT-ID.appspot.com または gs://STORAGE-REGION.artifacts.PROJECT-ID.appspot.com の形式で一覧表示されます。ここで、

    • PROJECT-ID は、Google Cloud プロジェクト ID です。 ドメインをスコープとするプロジェクトの場合、プロジェクト ID にドメイン名が含まれます。
    • STORAGE-REGION は、ストレージ バケットの場所です。
      • us。us.gcr.io ホストのレジストリの場合
      • eu: eu.gcr.io ホストのレジストリの場合
      • asia。asia.gcr.io ホストのレジストリの場合

  3. 次のコマンドを実行して、Container Registry のストレージ バケットを一般公開します。このコマンドは、バケット内のすべてのイメージを一般公開します。

    gcloud storage buckets add-iam-policy-binding gs://BUCKET-NAME \
    --member=allUsers --role=roles/storage.objectViewer

    ここで

    • gs://BUCKET-NAME は、Container Registry のバケット URL です。

イメージへの公開アクセス権を削除する

コンソール

  1. イメージを Container Registry に push し、基になるストレージ バケットが存在していることを確認します。

  2. Google Cloud コンソールで [Container Registry] ページを開きます。

    Container Registry ページを開く

  3. 左パネルの [設定] をクリックします。

  4. [設定] ページの [公開アクセス] で、公開設定を [非公開] に切り替えます。この設定は、基になるストレージ バケットへのアクセスを制御します。

gcloud storage

  1. そのレジストリの Cloud Storage バケットの名前を確認します。これを行うには、バケットを一覧表示します。

    gcloud storage ls

    Container Registry バケット URL は、gs://artifacts.PROJECT-ID.appspot.com または gs://STORAGE-REGION.artifacts.PROJECT-ID.appspot.com の形式で一覧表示されます。ここで、

    • PROJECT-ID は、Google Cloud Console プロジェクト ID です。ドメインをスコープとするプロジェクトの場合、プロジェクト ID にドメイン名が含まれます。
    • STORAGE-REGION は、ストレージ バケットの場所です。
      • us。us.gcr.io ホストのレジストリの場合
      • eu: eu.gcr.io ホストのレジストリの場合
      • asia。asia.gcr.io ホストのレジストリの場合

  2. ストレージ バケットへの公開アクセス権を削除するには、シェルまたはターミナル ウィンドウで次のコマンドを実行します。

    gcloud storage bucket remove-iam-policy-binding gs://BUCKET-NAME \
  --member=allUsers --role=roles/storage.objectViewer

ここで

  • BUCKET-NAME は目的のバケットの名前です。

権限を取り消す

IAM 権限を取り消すには、次の手順を実行します。

コンソール

  1. Google Cloud コンソールの [Cloud Storage] ページにアクセスします。

  2. バケットの artifacts.PROJECT-ID.appspot.com または STORAGE-REGION.artifacts.PROJECT-ID.appspot.com リンクをクリックします。PROJECT-ID は Container Registry をホストしているプロジェクトの Google Cloud プロジェクト ID であり、STORAGE-REGION は イメージをホストしているマルチリージョン（asia、eu、または us）です。

  3. [権限] タブを選択します。

  4. 削除するプリンシパルの横にあるごみ箱アイコンをクリックします。

gcloud

シェルまたはターミナル ウィンドウで次のコマンドを実行します。

gcloud storage bucket remove-iam-policy-binding gs://BUCKET-NAME \
    --member=PRINCIPAL --all

ここで

  • BUCKET-NAME は目的のバケットの名前です。
  • PRINCIPAL は、以下のいずれかになります。
    • user:EMAIL-ADDRESS。Google アカウントの場合
    • IAM サービスアカウントの serviceAccount:EMAIL-ADDRESS
    • group:EMAIL-ADDRESS。Google グループ用
    • allUsers。公開アクセスを取り消す場合

Google Cloud サービスと統合する

ほとんどの Google Cloud サービス アカウントでは、レジストリへのアクセスを構成するには、適切な IAM 権限を付与することのみ必要です。

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

Cloud Build や Google Kubernetes Engine などの Google Cloud サービスは、デフォルトのサービス アカウントまたはサービス エージェントを使用して、同じプロジェクト内のリソースを操作します。

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

  • Google Cloud サービスが Container Registry とは異なるプロジェクトにある。
  • デフォルトの権限ではニーズが満たされない。たとえば、デフォルトの Compute Engine サービス アカウントには、同じプロジェクトのストレージに対する読み取り専用アクセス権が付与されます。VM からレジストリにイメージを push する場合は、VM サービス アカウントの権限を変更するか、ストレージへの書き込みアクセス権を持つアカウントでレジストリに対して認証する必要があります。
  • Container Registry の操作にカスタム サービス アカウントを使用している

通常、次のサービス アカウントは Container 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 編集者ロール（ストレージへの読み取り専用アクセスに限定）

イメージを push するように VM とクラスタを構成する

Compute Engine と、Compute Engine を使用する Google Cloud サービスには、デフォルトの ID として Compute Engine のデフォルトのサービス アカウントがあります。

IAM 権限とアクセス スコープはどちらも、VM のストレージに対する読み取りと書き込みの機能に影響を与えます。

  • IAM 権限によって、リソースへのアクセス権が決まります。
  • アクセス スコープは、VM インスタンス上の gcloud CLI とクライアント ライブラリを介して行われるリクエストのデフォルトの OAuth スコープを決定します。結果的に、アクセス スコープでは、アプリケーションのデフォルト認証情報で認証する際に API メソッドへのアクセスをさらに制限できます。
    • 非公開イメージを pull するには、VM サービス アカウントに、イメージのストレージバケットに対する read 権限が必要です。
    • 非公開イメージを push するには、VM サービス アカウントに、イメージのストレージ バケットに対する read-write、cloud-platform、または full-control のアクセス スコープが必要です。

Compute Engine のデフォルトのサービス アカウントには、デフォルトで編集者のロールが付与されています。このロールには、ほとんどの Google Cloud サービスのリソースを作成および更新する権限が含まれています。ただし、デフォルトのサービス アカウント、または VM に関連付けるカスタム サービス アカウントの場合、ストレージ バケットのデフォルトのアクセス スコープは読み取り専用です。つまり、デフォルトでは VM はイメージを push できません。

Compute Engine や GKE などの環境にイメージをデプロイするだけの場合は、アクセス スコープを変更する必要はありません。これらの環境でアプリケーションを実行してイメージをレジストリに push する場合は、追加の構成を行う必要があります。

次の設定では、IAM 権限かアクセス スコープ構成のいずれかを変更する必要があります。

VM またはクラスタからイメージを push する
イメージを push するには、VM インスタンスのサービス アカウントに storage-ro ではなく storage-rw スコープが必要です。
VM と Container Registry は別々のプロジェクトにある場合
Container Registry が使用するストレージ バケットへアクセスするには、IAM 権限をサービス アカウントに付与する必要があります。
VM での gcloud コマンドの実行
サービス アカウントに cloud-platform スコープが必要です。このスコープは、push と pull および gcloud コマンドを実行する権限を付与します。

以降のセクションでは、スコープを構成する手順について説明します。

VM のスコープを構成する

VM の作成時にアクセス スコープを設定するには、-scopes オプションを使用します。

gcloud compute instances create INSTANCE --scopes=SCOPE

ここで

  • INSTANCE は VM インスタンス名です。
  • SCOPE は、VM サービス アカウントに構成するスコープです。
    • プルイメージ: storage-ro
    • イメージの pull と push: storage-rw
    • イメージの pull と push、gcloud コマンドの実行: cloud-platform

既存の VM インスタンスのスコープを変更するには:

-scopes オプションを使用してアクセス スコープを設定します。

  1. VM インスタンスを停止します。インスタンスの停止をご覧ください。

  2. 次のコマンドでアクセス スコープを変更します。

    gcloud compute instances set-service-account INSTANCE --scopes=SCOPE

    ここで

    • INSTANCE は VM インスタンス名です。
    • SCOPE は、VM サービス アカウントに構成するスコープです。
      • プルイメージ: storage-ro
      • イメージの pull と push: storage-rw
      • イメージの pull と push、gcloud コマンドの実行: cloud-platform

  3. VM インスタンスを再起動します。停止されたインスタンスの起動をご覧ください。

デフォルトのサービス アカウントの代わりに VM のカスタム サービス アカウントを使用する場合は、VM を作成するとき、および VM の設定を変更するときに、使用するサービス アカウントとアクセス スコープを指定できます。

Google Kubernetes Engine クラスタのスコープを構成する

デフォルトでは、Cloud Storage バケットの読み取り専用権限で新しい GKE クラスタが作成されます。

Google Kubernetes Engine クラスタの作成時に read-write ストレージ スコープを設定するには、--scopes オプションを使用します。たとえば、次のコマンドは、スコープ bigquery、storage-rw、compute-ro を持つクラスタを作成します。

gcloud container clusters create example-cluster \
--scopes=bigquery,storage-rw,compute-ro

新しいクラスタの作成時に設定できるスコープの詳細については、gcloud container clusters create コマンドのドキュメントをご覧ください。

Container Registry サービス アカウント

Container Registry サービス エージェントは、Google Cloud サービスを操作するときに Container Registry の代理として動作します。2020 年 10 月 5 日以降に Container Registry API を有効にした場合、このサービス エージェントには必要最小限の権限が割り当てられます。以前は、編集者ロールが付与されていました。サービス エージェントの概要とその権限の変更方法の詳細については、Container Registry サービス アカウントをご覧ください。

使ってみる

Google Cloud を初めて使用される方は、アカウントを作成して、実際のシナリオで Container Registry のパフォーマンスを評価してください。新規のお客様には、ワークロードの実行、テスト、デプロイができる無料クレジット $300 分を差し上げます。

Container Registry の無料トライアル