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

このページでは、Artifact Registry の Identity and Access Management(IAM)を使用したアクセス制御について説明します。

Artifact Registry のデフォルト権限により、CI/CD パイプラインの実装時の設定作業は最小限に抑えられています。Artifact Registry をサードパーティの CI/CD ツールと統合し、リポジトリへのアクセスに必要な権限と認証を構成することもできます。

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

始める前に

  1. Artifact Registry を有効にします。これには API の有効化と、Google Cloud CLI のインストールが含まれます。
  2. リポジトリ固有の権限を適用する場合は、パッケージ用の Artifact Registry リポジトリを作成します。

概要

IAM の権限ロールによって、Artifact Registry リポジトリ内のデータの作成、表示、編集、削除が可能かどうかが決まります。

ロールとは、一連の権限のことです。プリンシパルに直接権限を付与することはできません。代わりに、ロールを付与します。ロールをプリンシパルに付与する際には、ロールに含まれているすべての権限がプリンシパルに付与されます。同じプリンシパルに複数のロールを付与できます。

Google Cloud のデフォルトの権限

デフォルトでは、次の権限が Artifact Registry と同じプロジェクト内の Google Cloud CI/CD サービスに適用されます。

すべてのサービスが同じ Google Cloud プロジェクト内にあり、デフォルトの権限がニーズを満たしている場合は、権限を構成する必要はありません。

次の場合は、これらのサービスに対して Artifact Registry の権限を構成する必要があります。

  • これらのサービスを使用して、別のプロジェクトの Artifact Registry にアクセスする必要がある。Artifact Registry を使用するプロジェクトで、Workload Identity プールまたは各サービスのサービス アカウントに、必要なロールを付与します。Cloud Run に接続する場合は、Cloud Run サービス エージェントに必要なロールを付与します。
  • Artifact Registry からイメージを pull する組み込みのサポートがない GKE バージョンを使用している。構成手順については、GKE のセクションをご覧ください。
  • デフォルトのサービス アカウントにリポジトリへの読み取りと書き込みのアクセス権を付与する必要がある。詳しくは以下をご覧ください。
  • デフォルトのサービス アカウントではなく、ランタイム環境にユーザー指定のサービス アカウントを使用している。Artifact Registry を使用するプロジェクトで、必要なロールを付与します。

サードパーティとの統合

サードパーティのクライアントの場合は、権限と認証の両方を構成する必要があります。

従来の方法では、Google Cloud の外部で実行されているアプリケーションは、サービス アカウント キーを使用して Google Cloud リソースにアクセスします。ただし、サービス アカウント キーは強力な認証情報であり、正しく管理しなければセキュリティ上のリスクとなります。

Workload Identity 連携では、Identity and Access Management(IAM)を使用して外部 ID に IAM ロールを付与して、サービス アカウントの権限を借用するといったことができます。これにより、サービス アカウント キーに関連するメンテナンスとセキュリティの負担がなくなります。

Workload Identity 連携を使用する:

  1. Workload Identity 連携プールを作成します
  2. Workload Identity 連携プロバイダを作成します
  3. 適切な Artifact Registry ロールを Workload Identity プールに付与して、リポジトリへのアクセスを許可します。
  4. Artifact Registry で認証するようにサードパーティ クライアントを構成します。

サービス アカウントを使用する:

  1. アプリケーションに代わって動作するサービス アカウントを作成するか、CI/CD の自動化に使用する既存のサービス アカウントを選択します。
  2. 適切な Artifact Registry のロールをサービス アカウントに付与して、リポジトリへのアクセスを許可します。
  3. Artifact Registry で認証するようにサードパーティ クライアントを構成します。

Google Cloud での GitLab

GitLab on Google Cloud の統合では、Google Cloud 上の GitLab ワークロードの認可と認証に、Workload Identity 連携を使用します。サービス アカウントやサービス アカウント キーは必要ありません。このパートナーシップが Workload Identity 連携を使用する仕組みについて詳しくは、認証の概要をご覧ください。

Workload Identity 連携の設定と GitLab on Google Cloud に必要な IAM ロールについては、GitLab チュートリアルの Google Cloud Workload Identity 連携と IAM ポリシーをご覧ください。

Artifact Registry リポジトリを接続するには、GitLab のチュートリアル Google Artifact Registry の手順を行います。

ロールと権限

すべての Artifact Registry API メソッドでは、リクエストを行うプリンシパル(ユーザー、グループ、またはサービス アカウント)が、リソースの使用に必要な権限を持っている必要があります。リソースに対する事前定義ロールをプリンシパルに付与するポリシーを設定することで、プリンシパルに権限を付与します。

Google Cloud プロジェクトまたは Artifact Registry リポジトリにロールを付与できます。

Artifact Registry の事前定義ロール

IAM には事前定義ロールが用意されています。こうしたロールを使用すると、特定の Google Cloud リソースに対するアクセス権を付与し、それ以外のリソースへの無認可のアクセスを防止できます。

pkg.dev ドメインの標準リポジトリ、仮想リポジトリ、リモート リポジトリには、以下の事前定義ロールを使用します。

ロール 説明
Artifact Registry 読み取り
roles/artifactregistry.reader
アーティファクトの表示と取得、リポジトリのメタデータの表示。
Artifact Registry 書き込み
roles/artifactregistry.writer
アーティファクトを読み書きします。
Artifact Registry リポジトリ管理者
roles/artifactregistry.repoAdmin
アーティファクトの読み取り、書き込み、削除。
Artifact Registry 管理者
roles/artifactregistry.admin
リポジトリとアーティファクトの作成および管理。

次の追加の事前定義ロールには、gcr.io ドメインのイメージをホストする gcr.io リポジトリを作成する権限が含まれています。このロールには、pkg.dev ドメインの Artifact Registry で他のリポジトリ形式を作成する権限は含まれていません。Container Registry はコンテナ イメージの最初の push を使用して各マルチリージョン レジストリを作成するため、これらのロールは Container Registry との下位互換性をサポートします。

ロール 説明
Artifact Registry の Create-on-push Writer(roles/artifactregistry.createOnPushWriter アーティファクトを読み書きします。gcr.io リポジトリの作成
Artifact Registry の Create-on-push リポジトリ管理者(roles/artifactregistry.createOnPushRepoAdmin アーティファクトの読み取り、書き込み、削除。gcr.io リポジトリの作成

各ロールの個々の権限の完全なリストについては、Artifact Registry のロールをご覧ください。また、gcloud iam roles describe コマンドを使用して各ロールの権限のリストを表示することもできます。

IAM の基本ロール

基本ロールは、IAM の導入前に存在していた高い権限を持つロールです。基本ロールを使用して、プリンシパルに Google Cloud リソースへの広範なアクセス権を付与できます。

可能な限り、リポジトリへのアクセスに事前定義ロールを使用して、ユーザーとサービス アカウントに必要な権限のみが付与されるようにします。

基本ロールの詳細については、IAM の基本ロールと事前定義ロールのリファレンスをご覧ください。

権限の付与

同じ権限がプロジェクト内のすべてのリポジトリに適用される場合は、プロジェクト レベルで権限を付与します。一部のアカウントに異なるレベルのアクセス権が必要な場合は、リポジトリ レベルでロールを付与します。

仮想リポジトリに権限を付与する場合、これらの権限は、個々のリポジトリの権限に関係なく、仮想リポジトリを介して利用可能なすべてのアップストリーム リポジトリに適用されます。

gcloud コマンドを使用してロールを付与する場合は、プリンシパルに対して 1 つのロール バインディングを指定するか、ポリシー ファイルを使用して複数のバインディングを定義します。

プロジェクト全体の権限の付与

同じ権限がプロジェクト内のすべてのリポジトリに適用される場合は、プロジェクト レベルでロールを付与します。

ユーザーまたはサービス アカウントをプロジェクトに追加し、Artifact Registry のロールを付与するには:

コンソール

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

    [IAM] ページを開く

  2. [プロジェクトを選択] をクリックし、Artifact Registry が実行されているプロジェクトを選択して、[開く] をクリックします。

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

  4. メールアドレスを入力します。個人、サービス アカウント、Google グループをプリンシパルとして追加できます。

  5. プリンシパルのロールを選択します。最小権限のセキュリティ原則に従って、必要な Artifact Registry リソースにアクセスするために必要な最小限の権限を付与することを検討してください。Artifact Registry の事前定義ロールと権限については、Artifact Registry の事前定義ロールをご覧ください。

  6. [保存] をクリックします。

gcloud

  1. In the Google Cloud console, activate Cloud Shell.

    Activate Cloud Shell

    At the bottom of the Google Cloud console, a Cloud Shell session starts and displays a command-line prompt. Cloud Shell is a shell environment with the Google Cloud CLI already installed and with values already set for your current project. It can take a few seconds for the session to initialize.

  2. 単一のプリンシパルにロールを付与するには、次のコマンドを実行します。

    gcloud projects add-iam-policy-binding PROJECT \
       --member=PRINCIPAL \
       --role=ROLE
    

    ここで

    • PROJECT は、Artifact Registry が実行されているプロジェクトの ID です。
    • PRINCIPAL は、バインディングを追加するプリンシパルです。user|group|serviceAccount:email または domain:domain の形式を使用します。

      例: user:test-user@gmail.comgroup:admins@example.comserviceAccount:test123@example.domain.com、または domain:example.domain.com

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

    詳細については、add-iam-policy-binding のドキュメントをご覧ください。

    ポリシー ファイルを使用してロールを付与するには、次のコマンドを実行します。

    gcloud projects set-iam-policy PROJECT /PATH/TO/policy.yaml

    場所

    • PROJECT は、Artifact Registry が実行されているプロジェクトの ID または完全修飾識別子です。
    • /PATH/TO/policy.yaml は、ポリシー ファイルのパスとファイル名です。

    現在構成されているポリシーを取得するには、次のコマンドを実行します。

    gcloud projects get-iam-policy PROJECT

    PROJECT はプロジェクトの ID またはプロジェクトの完全修飾識別子です。

    詳細については、set-iam-policy のドキュメントをご覧ください。

リポジトリに固有の権限の付与

ユーザーやサービス アカウントにプロジェクトのリポジトリごとに異なるレベルのアクセス権を付与する場合は、リポジトリ レベルの権限を付与します。

コンソール

特定のリポジトリへのアクセス権を付与するには:

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

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

  2. 適切なリポジトリを選択します。

  3. 情報パネルが表示されていない場合は、メニューバーの [情報パネルを表示] をクリックします。

  4. [権限] タブで、[プリンシパルを追加] をクリックします。

  5. メールアドレスを入力します。個人、サービス アカウント、Google グループをプリンシパルとして追加できます。

  6. プリンシパルのロールを選択します。最小権限のセキュリティ原則に従って、必要な Artifact Registry リソースにアクセスするために必要な最小限の権限を付与することを検討してください。Artifact Registry の事前定義ロールと権限については、Artifact Registry の事前定義ロールをご覧ください。

  7. [保存] をクリックします。

gcloud

  1. In the Google Cloud console, activate Cloud Shell.

    Activate Cloud Shell

    At the bottom of the Google Cloud console, a Cloud Shell session starts and displays a command-line prompt. Cloud Shell is a shell environment with the Google Cloud CLI already installed and with values already set for your current project. It can take a few seconds for the session to initialize.

  2. 個別のポリシー バインディングの IAM セットを設定する、またはポリシー ファイルを使用することができます。

    単一のプリンシパルにロールを付与するには、次のコマンドを実行します。

    gcloud artifacts repositories add-iam-policy-binding REPOSITORY \
       --location=LOCATION \
       --member=PRINCIPAL \
       --role=ROLE
    

    ここで

    • REPOSITORY はリポジトリの ID です。
    • PRINCIPAL は、バインディングを追加するプリンシパルです。user|group|serviceAccount:email または domain:domain の形式を使用します。

      例: user:test-user@gmail.comgroup:admins@example.comserviceAccount:test123@example.domain.com、または domain:example.domain.com

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

    • LOCATION は、リポジトリのリージョンまたはマルチリージョンのロケーションです。

    たとえば、ユーザー write@gmail.com のロール roles/artifactregistry.writer に、ロケーション --us-central1 のリポジトリ my-repo を持つ IAM ポリシー バインディングを追加するには、次のコマンドを実行します。

    gcloud artifacts repositories add-iam-policy-binding my-repo \
    --location=us-central1 --member=user:write@gmail.com --role=roles/artifactregistry.writer
    

    ポリシー ファイルを使用してロールを付与するには、次のコマンドを実行します。

    gcloud artifacts repositories set-iam-policy REPOSITORY /PATH/TO/policy.yaml --location=LOCATION

    場所

    • REPOSITORY はリポジトリの ID です。
    • /PATH/TO/policy.yaml は、ポリシー ファイルのパスとファイル名です。
    • LOCATION は、リポジトリのリージョンまたはマルチリージョンのロケーションです。

    たとえば、policy.yaml で定義されたポリシーを使用して、ロケーション --us-central1 のリポジトリ my-repo の IAM ポリシーを設定するには、次のコマンドを実行します。

    gcloud artifacts repositories set-iam-policy my-repo policy.yaml --location=us-central1
    

Terraform

IAM ポリシーを構成するには、google_artifact_registry_repository_iam リソースを使用します。次の例では、リソース名が repo-account のサービス アカウントを定義し、リソース名が my-repo のリポジトリへの読み取りアクセス権を付与します。

Google Cloud で Terraform を初めて使用する場合は、HashiCorp ウェブサイトの Google Cloud スタートガイド ページをご覧ください。

provider "google" {
    project = "PROJECT-ID"
}

resource "google_artifact_registry_repository" "my-repo"     {
  provider = google-beta

  location = "LOCATION"
  repository_id = "REPOSITORY"
  description = "DESCRIPTION"
  format = "FORMAT"
}

resource "google_service_account" "repo-account" {
  provider = google-beta

  account_id   = "ACCOUNT-ID"
  display_name = "Repository Service Account"
}

resource "google_artifact_registry_repository_iam_member" "repo-iam" {
  provider = google-beta

  location = google_artifact_registry_repository.my-repo.location
  repository = google_artifact_registry_repository.my-repo.name
  role   = "roles/artifactregistry.reader"
  member = "serviceAccount:${google_service_account.repo-account.email}"
}

ACCOUNT-ID はサービス アカウントの ID です。これは、サービス アカウントのメール フィールドの @ 記号の前の部分です。

その他の例については、google_artifact_registry_repository_iam リソースのドキュメントをご覧ください。

リポジトリへの公開アクセスの構成

認証なしでインターネット上のすべてのユーザーが利用できるようすることが必要なアーティファクトがある場合は、一般公開するリポジトリに保存します。

公開読み取り専用アクセス権用のリポジトリを構成するには、プリンシパル allUsers に Artifact Registry 読み取りロールを付与します。また、1 人のユーザーがプロジェクト全体の割り当てを使い果たさないように、ユーザー リクエストの割り当ての上限を設定することをおすすめします。

コンソール

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

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

  2. 適切なリポジトリを選択します。

  3. 情報パネルが表示されていない場合は、メニューバーの [情報パネルを表示] をクリックします。

  4. [権限] タブで、[プリンシパルを追加] をクリックします。

  5. [新しいプリンシパル] フィールドに「allUsers」と入力します。

  6. [Artifact Registry 読み取り] ロールを選択します。

  7. 未認証ユーザーによる不正使用を防ぐために、Artifact Registry API リクエストにユーザーごとの上限を設定します。手順については、使用量の上限を設定するをご覧ください。

gcloud

  1. In the Google Cloud console, activate Cloud Shell.

    Activate Cloud Shell

    At the bottom of the Google Cloud console, a Cloud Shell session starts and displays a command-line prompt. Cloud Shell is a shell environment with the Google Cloud CLI already installed and with values already set for your current project. It can take a few seconds for the session to initialize.

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

    gcloud artifacts repositories add-iam-policy-binding REPOSITORY \
    --location=LOCATION --member=allUsers --role=ROLE
    

    ここで

    • REPOSITORY はリポジトリの ID です。

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

    • LOCATION は、リポジトリのリージョンまたはマルチリージョンのロケーションです。

    たとえば、ロケーション --us-central1 のリポジトリ my-repo を一般公開として構成するには、次のコマンドを実行します。

    gcloud artifacts repositories add-iam-policy-binding my-repo \
     --location=us-central1 --member=allUsers --role=roles/artifactregistry.reader
    
  3. 未認証ユーザーによる不正使用を防ぐために、Artifact Registry API リクエストにユーザーごとの上限を設定します。手順については、使用量の上限を設定するをご覧ください。

権限の取り消し

リポジトリへのアクセス権を取り消すには、承認されたプリンシパルのリストからプリンシパルを削除します。

リポジトリから公開アクセスを削除するには、allUsers プリンシパルを削除します。

コンソール

権限を取り消すには:

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

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

  2. 適切なリポジトリを選択します。

  3. 情報パネルが表示されていない場合は、メニューバーの [情報パネルを表示] をクリックします。

  4. [権限] タブで、適切なプリンシパルを展開します。公開リポジトリを非公開にする場合は、allUsers プリンシパルを展開します。

  5. [プリンシパルを削除] をクリックして、アクセス権を取り消します。

gcloud

  1. In the Google Cloud console, activate Cloud Shell.

    Activate Cloud Shell

    At the bottom of the Google Cloud console, a Cloud Shell session starts and displays a command-line prompt. Cloud Shell is a shell environment with the Google Cloud CLI already installed and with values already set for your current project. It can take a few seconds for the session to initialize.

  2. プロジェクト レベルでロールを取り消すには、次のコマンドを実行します。

    gcloud projects remove-iam-policy-binding PROJECT \
       --member=PRINCIPAL \
       --role=ROLE
    
    • PROJECT は、プロジェクト ID です。
    • PRINCIPAL は、バインディングを削除するプリンシパルです。user|group|serviceAccount:email または domain:domain の形式を使用します。

      例: user:test-user@gmail.comgroup:admins@example.comserviceAccount:test123@example.domain.com、または domain:example.domain.com

    • ROLE は、取り消すロールです。

    リポジトリのロールを取り消すには、次のコマンドを実行します。

    gcloud artifacts repositories remove-iam-policy-binding REPOSITORY
       --location=LOCATION \
       --member=PRINCIPAL \
       --role=ROLE
    

    ここで

    • REPOSITORY はリポジトリの ID です。
    • PRINCIPAL は、バインディングを削除するプリンシパルです。user|group|serviceAccount:email または domain:domain の形式を使用します。

      例: user:test-user@gmail.comgroup:admins@example.comserviceAccount:test123@example.domain.com、または domain:example.domain.com

      リポジトリへの公開アクセスを取り消すには、プリンシパル allUsers を指定します。

    • ROLE は、取り消すロールです。

    たとえば、--us-central1 ロケーションのリポジトリ my-repo を持つユーザー write@gmail.com のロール roles/artifactregistry.writer のポリシー バインディングを削除するには、次のコマンドを実行します。

    gcloud artifacts repositories remove-iam-policy-binding my-repo \
       --location=us-central1 \
       --member=user:write@gmail.com \
       --role=roles/artifactregistry.writer

    ロケーション --us-central1my-repo への公開アクセス権を取り消すには、次のコマンドを実行します。

    gcloud artifacts repositories remove-iam-policy-binding my-repo \
       --location=us-central1 \
       --member=allUsers \
       --role=roles/artifactregistry.reader
    

タグを使用した条件付きのアクセス権の付与

プロジェクト管理者は、Google Cloud のリソースにタグを作成し、Resource Manager で管理できます。Artifact Registry リポジトリにタグ付けすると、管理者は IAM 条件を伴うタグを使用して、リポジトリに条件付きのアクセス権を付与できます。

個々のアーティファクトにタグ付けすることはできません。

詳細については、以下のドキュメントをご覧ください。

Google Cloud サービスとの統合

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

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

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

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

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

通常、次のサービス アカウントは Artifact 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
デフォルトの権限には、リポジトリに対する読み取り / 書き込みアクセス権と、gcr.io リポジトリの作成機能が含まれます。
Cloud Run Cloud Run サービス エージェント
run.googleapis.com のサービス エージェント。
service-PROJECT-NUMBER@serverless-robot-prod.iam.gserviceaccount.com 読み取り権限(リポジトリへの読み取り専用アクセスに限定)
GKE Compute Engine のデフォルトのサービス アカウント
ノードのデフォルトのサービス アカウント。
PROJECT-NUMBER-compute@developer.gserviceaccount.com 編集者ロール(リポジトリの読み取り専用アクセスに限定)

Compute Engine インスタンスへのアクセス権の付与

リポジトリにアクセスする VM インスタンスには、Artifact Registry 権限とストレージ アクセス スコープの両方が構成されている必要があります。

サービス アカウントのアクセスレベルはサービス アカウントに付与された IAM ロールによって決定されますが、VM インスタンスのアクセス スコープによって、インスタンスの gcloud CLI とクライアント ライブラリを使用して行われるリクエストのデフォルトの OAuth スコープが決定されます。そのため、アクセス スコープでは、アプリケーションのデフォルト認証情報で認証する際に API メソッドへのアクセスをさらに制限できます。

Compute Engine では、次のデフォルトが使用されます。

  • Compute Engine のデフォルトのサービス アカウントが VM インスタンスの ID となっています。サービス アカウントのメールアドレスには、@developer.gserviceaccount.com というサフィックスが付加されています。
  • この動作を無効にしていない場合、このデフォルトのサービス アカウントには IAM の基本の編集者のロールがあります。
  • デフォルトのサービス アカウントで作成したインスタンスには、Compute Engine のデフォルトのアクセス スコープ(ストレージへの読み取り専用アクセス権を含む)が設定されています。編集者ロールは通常、書き込みアクセス権を付与するものであるのに対して、read-only ストレージ アクセス スコープは、インスタンスのサービス アカウントに対し、アーティファクトのダウンロードについて、同じプロジェクトのリポジトリからのみとする制限を課します。

次の場合に、サービス アカウントのアクセス範囲を構成する必要があります。

  • VM サービス アカウントが、別のプロジェクト内のリポジトリにアクセスする必要がある。
  • VM サービス アカウントは、リポジトリからアーティファクトを読み取る以外のアクションを実行する必要がある。これは通常、イメージを push するか Artifact Registry の gcloud コマンドを実行する必要がある VM にサードパーティ ツールを適用することによって実現します。

権限を構成してアクセス スコープを設定するには:

  1. VM インスタンスを含むプロジェクトで、Compute Engine のデフォルト サービス アカウントの名前を取得します。サービス アカウントのメールアドレスには、@developer.gserviceaccount.com というサフィックスが付加されています。

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

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

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

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

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

      SCOPE は、適切な値に置き換えます。

      • Docker では、次のオプションがサポートされます。

        • storage-ro - イメージの pull のみを許可する読み取り権限を付与します。
        • storage-rw - イメージを push または pull するための読み取りと書き込みの権限を付与します。
        • cloud-platform - メタデータを含む Google Cloud サービス全体のデータを表示して管理します。
      • 他の形式の場合は、cloud-platform スコープを使用する必要があります。

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

Google Kubernetes Engine クラスタへのアクセス権の付与

GKE クラスタとノードプールは、次の要件がすべて満たされていれば、追加の構成なしでコンテナを pull できます。

GKE 環境がこれらの要件を満たしていない場合は、Compute Engine のデフォルト サービス アカウントを使用しているか、ユーザーから提供されたアカウントをノードの ID として使用しているかによって、アクセス権を付与する手順が異なります。

デフォルト サービス アカウント

次の構成要件は、Compute Engine のデフォルト サービス アカウントに適用されます。

  1. GKE が Artifact Registry とは異なるプロジェクトにある場合、必要な権限をサービス アカウントに付与します。

  2. イメージを push するには、コンテナ以外の形式のリポジトリを操作するか、クラスタから gcloud コマンドを実行して、クラスタまたはノードプールを作成する際にサービス アカウントのアクセス スコープを設定する必要があります。

  3. GKE のサポートされているバージョンを使用していない場合は、imagePullSecrets を構成します。

ユーザー指定のサービス アカウント

ユーザーが指定したサービス アカウントをクラスタの ID として使用する場合は、次の操作を行う必要があります。

  1. Artifact Registry が実行されている Google Cloud プロジェクトから、サービス アカウントに必要な権限を付与します。

  2. デフォルトでは、ユーザー指定のサービス アカウントを使用してクラスタまたはノードプールを作成すると、cloud-platform アクセス スコープが付与されます。

    gcloud container clusters create コマンドまたは gcloud container node-pools create コマンドで --scopes フラグを使用する場合は、以下を含める必要があります。Artifact Registry で使用する適切なアクセス スコープ

アクセス スコープの設定

アクセス スコープは、Compute Engine VM の認可を指定する以前の方法です。Artifact Registry リポジトリからイメージを pull するには、GKE ノードにストレージの読み取り専用アクセス スコープ、またはストレージ読み取りアクセス権を含む別のストレージ アクセス スコープが必要です。

アクセス スコープは、クラスタまたはノードプールを作成する場合にのみ設定できます。既存のノードではアクセス スコープを変更できません。

  • もし Compute Engine のデフォルトのサービス アカウントを使用している場合、GKE は Compute Engine デフォルトのアクセス スコープを使用してノードを作成します。これにはストレージへの読み取り専用アクセスが含まれます。
  • ユーザーが指定したサービス アカウントを使用している場合、GKE は cloud-platform スコープ(ほとんどの Google Cloud サービスに必要なスコープ)を使用してノードを作成します。

クラスタの作成時にアクセス スコープを指定するには、次のコマンドを実行します。

gcloud container clusters create NAME --scopes=SCOPES

ノードプールの作成時にアクセス スコープを指定するには、次のコマンドを実行します。

gcloud container node-pools create NAME --scopes=SCOPES

次の値を置き換えます。

  • NAME は、クラスタまたはノードプールの名前です。
  • SCOPES は、付与するアクセス スコープのカンマ区切りリストです。

    • Docker リポジトリにアクセスするには、次のいずれかのスコープを使用します。

    • storage-ro - イメージを pull するための読み取り専用権限を付与します。

    • storage-rw - イメージを push または pull するための読み取りと書き込みの権限を付与します。

    • cloud-platform - メタデータを含む Google Cloud サービス全体のデータを表示して管理します。

    • 他のリポジトリにアクセスするには、cloud-platform スコープを使用する必要があります。

    スコープの一覧については、gcloud container clusters create または gcloud container node-pools create のドキュメントをご覧ください。

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

imagePullSecret の構成

imagePullSecret を構成するには:

  1. GKE を使用するプロジェクトで、Compute Engine のデフォルトのサービス アカウントを探します。アカウントのメールアドレスには、@developer.gserviceaccount.com というサフィックスが付加されています。

  2. サービス アカウントのサービス アカウント キーをダウンロードします。

  3. リポジトリを含むプロジェクトで、リポジトリに権限を付与済みであることを確認します。

  4. クラスタを含むプロジェクトで、サービス アカウント キーを使用して artifact-registry と呼ばれる imagePullSecret シークレットを作成します。

    kubectl create secret docker-registry artifact-registry \
    --docker-server=https://LOCATION-docker.pkg.dev \
    --docker-email=SERVICE-ACCOUNT-EMAIL \
    --docker-username=_json_key \
    --docker-password="$(cat KEY-FILE)"
    

    場所

    • LOCATION は、リポジトリのリージョンまたはマルチリージョンのロケーションです。
    • SERVICE-ACCOUNT-EMAIL は、Compute Engine サービス アカウントのメールアドレスです。
    • KEY-FILE は、サービス アカウント キー ファイルの名前です。例: key.json
  5. デフォルトのサービス アカウントを開きます。

    kubectl edit serviceaccount default --namespace default

    Kubernetes クラスタ内のすべての名前空間には、default というデフォルトのサービス アカウントがあります。このデフォルト サービス アカウントは、コンテナ イメージを pull するために使用されます。

  6. 新しく作成した imagePullSecret シークレットをデフォルトのサービス アカウントに追加します。

    imagePullSecrets:
    - name: artifact-registry
    

    サービス アカウントは次のようになります。

    apiVersion: v1
    kind: ServiceAccount
    metadata:
      name: default
      namespace: default
      ...
    secrets:
    - name: default-token-zd84v
    # The secret you created:
    imagePullSecrets:
    - name: artifact-registry
    

これで、現在の default 名前空間に作成された新しいポッドには、imagePullSecret シークレットが定義されます。

Artifact Registry サービス アカウント

Artifact Registry サービス エージェントは、Google Cloud サービスを操作するときに Artifact Registry の代理として動作する Google マネージド サービス アカウントです。このアカウントとその権限の詳細については、Artifact Registry サービス アカウントをご覧ください。

次のステップ

権限の設定後に、アーティファクトの操作に関する詳細を確認する。