アクセス制御の構成

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

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

一般的なアクセス要件

Container Registry とやり取りするすべてのユーザー、サービス アカウント、その他の ID には、Cloud Storage ストレージに対する適切な Identity and Access Management(IAM)権限が必要です。

Google Kubernetes Engine クラスタ内の VM を含む Compute Engine VM で使用されるサービス アカウントの場合、アクセスは IAM 権限とアクセス スコープの両方に基づきます。

IAM の権限

Identity and Access Management の権限によって、リソースにアクセスできるユーザーが決まります。Container Registry とやり取りするすべてのユーザー、サービス アカウント、その他の ID には、適切な Cloud Storage の権限が必要です。

デフォルトでは、Google Cloud はデフォルトのサービス アカウントを使用して同じプロジェクト内のリソースを操作します。たとえば、Container Registry が同じプロジェクトにある場合、Cloud Build サービス アカウントはイメージの push と pull の両方を行うことができます。

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

  • あるプロジェクトのサービス アカウントを使用して別のプロジェクトの Container Registry にアクセスしている
  • ストレージへの読み取り専用アクセス権を持つデフォルトのサービス アカウントを使用しているが、イメージの pull と push の両方を行う必要がある
  • Container Registry の操作にカスタム サービス アカウントを使用している

VM とクラスタのアクセス スコープ

Compute Engine VM(GKE クラスタ内の VM を含む)に関連付けられたサービス アカウントの場合、ストレージへのアクセスは、IAM 権限と構成されたストレージ アクセス スコープの両方に基づきます。

Compute Engine のデフォルトのサービス アカウントは、VM と同じプロジェクト内のイメージを pull するよう構成されています。イメージを pull したり、別のプロジェクトで Container Registry を操作するため VM または GKE クラスタが必要な場合、Google Cloud での Container Registry の使用をご覧ください。

IAM 権限の構成

Container Registry は、コンテナ イメージの基盤となるストレージとして Cloud Storage バケットを使用します。イメージへのアクセスを制御するには、ユーザー、グループ、サービス アカウント、またはその他の ID に適切な Cloud Storage 権限を付与します。

プロジェクト レベルで付与された Cloud Storage 権限は、Container Registry で使用されるバケットだけでなく、プロジェクト内のすべてのストレージ バケットに適用されます。Container Registry に固有の権限を構成するには、レジストリが使用するストレージ バケットに権限を付与します。Container Registry は、ストレージ バケット内の個々のオブジェクトに設定された権限を無視します。

プロジェクト レベルのロールである OwnerEditorViewer を使用してアクセス権を付与することもできますが、Cloud Storage のロールでは、最小権限のセキュリティ原則を適用できます。これは、ユーザーとアカウントに必要な権限のみを付与するものです。

Google Cloud とやり取りする Google Cloud プロダクトとアプリケーションは、サービス アカウントを使用して Container Registry を操作します。サービス アカウントへのアクセスには、次の考慮事項が適用されます。

  • デフォルトでは、一部の一般的な統合のサービス アカウントは、同じプロジェクト内の Container Registry にアクセスできるように構成されています。たとえば、デフォルトでは、Cloud Build サービス アカウントは同じプロジェクト内のイメージの push と pull ができます。
  • サービス アカウントが別のプロジェクトの Container Registry にアクセスする必要がある場合、Container Registry を使用してプロジェクトで必要とされる権限を付与する必要があります。
  • VM インスタンス(Google Kubernetes Engine クラスタ内のインスタンスを含む)には、イメージを push または pull するための正しいストレージ アクセス スコープが構成されている必要があります。 デフォルトでは、VM は Container Registry が同じプロジェクトにある場合にイメージを pull できます。

権限とロール

次の表に、Container Registry の操作に必要な権限とロールを示します。

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

操作 権限 役割 役割のタイトル
push(読み書き)

storage.buckets.create

storage.buckets.delete

storage.buckets.get

storage.buckets.list

storage.buckets.update

storage.objects.create

storage.objects.delete

storage.objects.get

storage.objects.list

storage.objects.update

roles/storage.admin ストレージ管理者
pull(読み取り専用)

storage.objects.get

storage.objects.list

roles/storage.objectViewer ストレージ オブジェクト閲覧者

IAM 権限の付与

Container Registry が使用するストレージ バケットに対する権限を付与します。

権限の付与

  1. Container Registry ホストの場所(gcr.io、asia.gcr.io、eu.gcr.io、us.gcr.io)がプロジェクトに存在しない場合は、オーナー、編集者、ストレージ管理者の権限を持つユーザーがイメージをホストに push してストレージ バケットを作成します。
  2. Container Registry を使用するプロジェクトで、ホスト名により使用される Cloud Storage バケットに適切な権限を付与します。

    イメージを保存するバケットは、以下のフォームの名前 BUCKET-NAME を持っています。

    • gcr.io ホスト内のレジストリに push されたイメージの場合は、artifacts.PROJECT-ID.appspot.com
    • STORAGE-REGION.artifacts.PROJECT-ID.appspot.com

    ここで

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

    バケットの権限を付与するには、Google Cloud Console または gsutil コマンドライン ツールを使用します。

    Console

    1. Cloud Console の Cloud Storage ページにアクセスします。
    2. バケットの artifacts.PROJECT-ID.appspot.com または STORAGE-REGION.artifacts.PROJECT-ID.appspot.com リンクをクリックします。

      PROJECT-ID は Container Registry をホストしているプロジェクトの Google Cloud プロジェクト ID であり、STORAGE-REGION は イメージをホストしているマルチリージョンasiaeu、または us)です。

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

    4. [メンバーを追加] をクリックします。

    5. 表示されるメニューで、[メンバー] フィールドに、権限が必要なユーザーのメールアドレスをカンマで区切って入力します。このメールアドレスは、次のいずれかになります。

      • Google アカウント(例: someone@example.com
      • Google グループ(例: my-developer-team@googlegroups.com
      • IAM サービス アカウント
      • 別のプロジェクトの Compute Engine デフォルト サービス アカウント。このアカウントは、Google Kubernetes Engine がコンテナ イメージ クラスタを pull する場合に使用するデフォルトのアカウントです。形式は PROJECT-NUMBER-compute@developer.gserviceaccount.com になります。ここで、PROJECT-NUMBER は Google Kubernetes Engine クラスタを実行しているプロジェクトの Google Cloud プロジェクト番号です。
    6. [ロールを選択]プルダウン メニューから [ストレージ]カテゴリを選択し、適切な権限を選択します。

      • Storage Object Viewer。イメージのみを pull する場合。
      • ストレージオブジェクト管理者。イメージを push および pull する場合。
    7. [追加] をクリックします。

    gsutil

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

      gsutil ls
      

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

      gs://[BUCKET_NAME1]/
      gs://[BUCKET_NAME2]/
      gs://[BUCKET_NAME3]/ ...
      
    2. シェルまたはターミナル ウィンドウで次のコマンドを実行します。

      gsutil iam ch TYPE:EMAIL-ADDRESS:ROLE gs://BUCKET_NAME
      

      ここで

      • TYPE は、以下のいずれかになります。
        • serviceAccountEMAIL-ADDRESS がサービス アカウントを指定している場合。
        • userEMAIL-ADDRESS が Google アカウントの場合。
        • groupEMAIL-ADDRESS が Google グループの場合。
      • EMAIL-ADDRESS は、以下のいずれかになります。
        • Google アカウント(例: someone@example.com
        • Google グループ(例: my-developer-team@googlegroups.com
        • IAM サービス アカウント
        • 別のプロジェクトの Compute Engine デフォルト サービス アカウント。このアカウントは、Google Kubernetes Engine がコンテナ イメージ クラスタを pull する場合に使用するデフォルトのアカウントです。形式は PROJECT_NUMBER-compute@developer.gserviceaccount.com になります。ここで、PROJECT_NUMBER は Google Kubernetes Engine クラスタを実行しているプロジェクトの Google Cloud プロジェクト番号です。
      • ROLE は、付与する Cloud Storage のロールです。
        • objectViewer。イメージを pull する場合。
        • objectAdmin。イメージを push および pull する場合。
      • BUCKET_NAME は、artifacts.PROJECT-ID.appspot.com または STORAGE-REGION.artifacts.PROJECT-ID.appspot.com の形式の Cloud Storage バケットの名前です。

    gsutil iam ch コマンドは、レジストリがホストされているストレージ バケットの IAM 権限を変更します。アカウントに objectViewer 権限を付与すると、レジストリからイメージを pull できるようになります。

    コマンドの詳細については、gsutil iam のドキュメントをご覧ください。

  3. Compute Engine と Google Kubernetes Engine は、同じプロジェクトの Container Registry からデフォルトでイメージを pull する権限で構成されています。これらの統合にその他の要件がある場合は、Google Cloud サービスとの統合をご覧ください。

イメージへの公開アクセスの構成

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

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

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

Console

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

  2. Cloud Console で Container Registry ページを開きます。

    Container Registry ページを開く

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

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

    ホストの公開設定が一般公開になっている場合、そのホストにある Google Cloud プロジェクトのすべてのイメージが一般公開されます。

gsutil

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

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

    gsutil 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 は、ストレージ バケットの場所です。
      • usus.gcr.io ホストのレジストリの場合
      • eueu.gcr.io ホストのレジストリの場合
      • asiaasia.gcr.io ホストのレジストリの場合
  3. 次のコマンドを実行して、Container Registry のストレージ バケットを一般公開します。このコマンドは、バケット内のすべてのイメージを一般公開します。

    gsutil iam ch allUsers:objectViewer gs://BUCKET-NAME
    

    ここで

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

Container Registry が一般公開されている場合、誰でもそのイメージを pull できます。手順については、レジストリからイメージを pull するをご覧ください。

権限の取り消し

IAM 権限を取り消すには、次の手順に従います。

コンソール

  1. Cloud Console の Cloud Storage ページにアクセスします。
  2. バケットの artifacts.PROJECT-ID.appspot.com または STORAGE-REGION.artifacts.PROJECT-ID.appspot.com リンクをクリックします。PROJECT-ID は Container Registry をホストしているプロジェクトの Google Cloud プロジェクト ID であり、STORAGE-REGION は イメージをホストしているマルチリージョンasiaeu、または us)です。

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

  4. 削除するメンバーの横にあるごみ箱アイコンをクリックします。

gsutil

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

gsutil iam ch -d MEMBER gs://BUCKET-NAME

ここで

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

Google Cloud サービスとの統合

デフォルトでは、一部の一般的な統合のサービス アカウントは、同じプロジェクト内で pull アクセスのみ、または pull および push アクセスのいずれかに構成されています。アクセスは IAM 権限に基づいており、サービス アカウントが別のプロジェクトの Container Registry に接続する場合にのみ、権限を構成する必要があります。

Compute Engine のVM インスタンス(GKE クラスタ内の VM を含む)に関連付けられたサービス アカウントには、追加の要件があります。ストレージへの VM アクセスは、付与された IAM 権限とストレージ アクセス スコープに基づきます。

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

デフォルトでは、Compute Engine のデフォルトのデフォルトサービス アカウントには、同じプロジェクト内のリソースと read-only ストレージ アクセス スコープに対する編集権限があります。read-only スコープは、VM がイメージのみを pull するよう制限します。デフォルトのサービス アカウントには、@developer.gserviceaccount.com という接尾辞が付いています。

次の設定では、デフォルトの権限またはスコープの構成を変更する必要があります。

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

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

VM の IAM 権限の構成

デフォルトでは、Compute Engine VM は同じプロジェクト内のストレージにのみアクセスできます。VM が別のプロジェクトの Container Registry にアクセスする必要がある場合は、VM サービス アカウントに権限を付与する必要があります。

  1. VM インスタンスを含むプロジェクトで、Compute Engine のデフォルト サービス アカウントの名前、または VM インスタンスに関連付けられたサービス アカウントを取得します。デフォルトのサービス アカウントには、@developer.gserviceaccount.com という接頭辞が付いています。

  2. Container Registry を含むプロジェクトで、サービス アカウントが Container Registry にアクセスできるように権限を付与します。

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 インスタンスを再起動します。停止されたインスタンスの起動をご覧ください。

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

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

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

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

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