Container Registry は非推奨で、提供終了となります。2024 年 5 月 15 日より、Container Registry の使用歴がないプロジェクトでは、Artifact Registry が gcr.io ドメインのイメージをホストします。2025 年 3 月 18 日以降、Container Registry は提供終了となります。

Google Cloud でコンテナの管理を始めるには、Artifact Registry を使用してください。Container Registry を使用している場合は、Artifact Registry に移行して Google Cloud でコンテナを管理する方法をご確認ください。

サポート終了とシャットダウンの詳細については、サポート終了ページとリリースノートをご覧ください。

このページは Cloud Translation API によって翻訳されました。

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 ストレージバケットに対しても均一なバケットレベルのアクセスを有効にする場合は、レジストリにアクセスするすべてのユーザーとサービスアカウントに権限を明示的に付与する必要があります。この場合、オーナーロールと編集者ロールで必要な権限が付与されないことがあります。

権限を付与する

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

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

Docker を使用して最初のイメージを push する方法の詳細については、レジストリの追加をご覧ください。
Container Registry を使用するプロジェクトで、レジストリホストにより使用される Cloud Storage バケットに適切な権限を付与します。

注: Storage レガシーバケット書き込み権限をプロジェクトレベルで付与することはできません。また、プロジェクト全体で Storage オブジェクト閲覧者の権限を付与すると、すべてのストレージバケット（Container Registry が使用していないものを含む）へのアクセス権が付与されます。
コンソール
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. [追加] をクリックします。
注: メールアドレスとドメインは、有効な Google アカウントまたは Google Apps アカウントに関連付けられている必要があります。
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 bucket 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 bucket add-iam-policy-binding gs://my-example-bucket \
  --member=serviceAccount:my-account@my-project.iam.gserviceaccount.com \
  --role=roles/storage.objectUser
```
gcloud storage bucket add-iam-policy-binding コマンドは、レジストリがホストされているストレージバケットの IAM 権限を変更します。他の例については、gcloud CLI のドキュメントをご覧ください。

注: メールアドレスとドメインは、有効な Google アカウントまたは Google Apps アカウントに関連付けられている必要があります。
イメージを Container Registry に push する Compute Engine VM や GKE ノードへのアクセスを構成する場合は、VM とクラスタの構成で追加の構成手順をご覧ください。

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

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

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

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

イメージを Container Registry に push し、基になるストレージバケットが存在していることを確認します。
そのレジストリの 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 ホストのレジストリの場合
次のコマンドを実行して、Container Registry のストレージバケットを一般公開します。このコマンドは、バケット内のすべてのイメージを一般公開します。
```
gcloud storage bucket add-iam-policy-binding gs://BUCKET-NAME \
    --member=allUsers --role=roles/storage.objectViewer
```
ここで
- gs://BUCKET-NAME は、Container Registry のバケット URL です。

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

コンソール

イメージを Container Registry に push し、基になるストレージバケットが存在していることを確認します。
Google Cloud コンソールで [Container Registry] ページを開きます。

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

gcloud storage

そのレジストリの 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 ホストのレジストリの場合
ストレージバケットへの公開アクセス権を削除するには、シェルまたはターミナルウィンドウで次のコマンドを実行します。
```
gcloud storage bucket remove-iam-policy-binding gs://BUCKET-NAME \
  --member=allUsers --role=roles/storage.objectViewer
```

ここで

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

権限を取り消す

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

コンソール

Google Cloud コンソールの [Cloud Storage] ページにアクセスします。
バケットの artifacts.PROJECT-ID.appspot.com または STORAGE-REGION.artifacts.PROJECT-ID.appspot.com リンクをクリックします。PROJECT-ID は Container Registry をホストしているプロジェクトの Google Cloud プロジェクト ID であり、STORAGE-REGION はイメージをホストしているマルチリージョン（asia、eu、または us）です。
[権限] タブを選択します。
削除するプリンシパルの横にあるごみ箱アイコンをクリックします。

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 オプションを使用してアクセススコープを設定します。

VM インスタンスを停止します。インスタンスの停止をご覧ください。
次のコマンドでアクセススコープを変更します。
```
gcloud compute instances set-service-account INSTANCE --scopes=SCOPE
```
ここで
- INSTANCE は VM インスタンス名です。
- SCOPE は、VM サービスアカウントに構成するスコープです。
  - プルイメージ: storage-ro
  - イメージの pull と push: storage-rw
  - イメージの pull と push、gcloud コマンドの実行: cloud-platform
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 の無料トライアル

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

始める前に

権限と役割

IAM 権限を付与する

制限事項

権限を付与する

コンソール

gcloud

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

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

コンソール

gcloud storage

権限を取り消す

コンソール

gcloud

Google Cloud サービスと統合する

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

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

VM のスコープを構成する

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

Container Registry サービス アカウント

使ってみる

Container Registry サービスアカウント