アクセス制御の構成

このページでは、Artifact Registry リポジトリに権限を付与する方法について説明します。

始める前に

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

概要

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

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

Google Cloud との統合

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

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

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

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

サードパーティとの統合

サードパーティ アプリケーションの場合は、権限と認証の両方を構成する必要があります。

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

役割と権限

権限が含まれるロールを付与して、Identity and Access Management(IAM)権限を付与します。Artifact Registry のロールを使用して、リポジトリへのアクセスを制御します。プロジェクト レベルまたはリポジトリ レベルで権限を付与できます。

基本ロール OwnerEditorViewer を使用してリポジトリへのアクセス権を付与できますが、Artifact Registry のロールを使用すると、最小権限のセキュリティ原則を適用して、ユーザーとサービス アカウントに必要な権限のみを付与できます。

Artifact Registry の権限

次の表に、Artifact Registry の IAM ロールとロールに含まれる権限を示します。

役割 説明 権限
roles/artifactregistry.reader Artifact Registry 読み取り

アーティファクトの表示と取得

  • artifactregistry.repositories.list
  • artifactregistry.repositories.get
  • artifactregistry.repositories.downloadArtifacts
  • artifactregistry.files.list
  • artifactregistry.files.get
  • artifactregistry.packages.list
  • artifactregistry.packages.get
  • artifactregistry.tags.list
  • artifactregistry.tags.get
  • artifactregistry.versions.list
  • artifactregistry.versions.get
roles/artifactregistry.writer Artifact Registry 書き込み

アーティファクトの読み取りと書き込み

すべての roles/artifactregistry.reader 権限、および

  • artifactregistry.repositories.uploadArtifacts
  • artifactregistry.tags.create
  • artifactregistry.tags.update
roles/artifactregistry.repoAdmin Artifact Registry リポジトリ管理者

アーティファクトの読み取り、書き込み、削除

すべての roles/artifactregistry.writer 権限、および

  • artifactregistry.repositories.deleteArtifacts
  • artifactregistry.packages.delete
  • artifactregistry.tags.delete
  • artifactregistry.versions.delete
roles/artifactregistry.admin Artifact Registry 管理者

リポジトリとアーティファクトの作成および管理

すべての roles/artifactregistry.repoAdmin 権限、および

  • artifactregistry.repositories.create
  • artifactregistry.repositories.update
  • artifactregistry.repositories.delete
  • artifactregistry.repositories.getIamPolicy
  • artifactregistry.repositories.setIamPolicy

次の表に、IAM のリリース前に存在していた基本ロールと、基本ロールに含まれる Artifact Registry の IAM ロールの一覧を示します。

役割 役割のタイトル 含まれるロール
roles/viewer 閲覧者 roles/artifactregistry.reader
roles/editor 編集者 roles/artifactregistry.writer
roles/owner オーナー
  • roles/artifactregistry.repoAdmin
  • roles/artifactregistry.admin

権限の付与

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

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

このページの例には、次のリファレンス ポリシー テンプレートを使用しています。参照ポリシー ファイルの名前は policy.yaml です。テンプレートには、サンプルのユーザーとサービス アカウント名が含まれます。以下のサンプル ユーザーとサービス アカウントをプロジェクトに合わせて置き換えてください。

ポリシーの形式について詳しくは、IAM ポリシーのドキュメントをご覧ください。

bindings:

- members:
  - user: user@gmail.com
  role: roles/owner

- members:
  - serviceAccount: repo-readonly@iam.gserviceaccount.com
  - user: user2@gmail.com
  role: roles/artifactregistry.reader

- members:
  - serviceAccount: repo-write@iam.gserviceaccount.com
  role: roles/artifactregistry.writer

- members:
  - serviceAccount: repo-admin@iam.gserviceaccount.com
  role: roles/artifactregistry.repoAdmin

- members:
  - serviceAccount: ar-admin@iam.gserviceaccount.com
  role: roles/artifactregistry.admin

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

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

チームメンバーをプロジェクトに追加し、Artifact Registry のロールを付与するには:

コンソール

  1. Cloud Console で IAM ページを開きます。

    [IAM] ページを開く

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

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

  4. メールアドレスを入力します。個人、サービス アカウント、Google グループをメンバーとして追加できます。アルファ版機能を使用するには、ユーザーが Google グループ ar-trusted-testers@googlegroups.com のメンバーであることが必要です。

  5. メンバーのロールを選択します。最小権限のセキュリティ原則に従って、他のリソースへの不要なアクセスを防止するために最小限の権限を付与することを検討してください。

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

gcloud

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

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

ここで

  • PROJECT は、Artifact Registry が実行されているプロジェクトの ID です。
  • MEMBER は、バインディングを追加するメンバーです。 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. Cloud Console で [リポジトリ] ページを開きます。

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

  2. 該当するリポジトリを選択します。

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

  4. [権限] タブで、[メンバーを追加] をクリックします。

  5. メールアドレスを入力します。個人、サービス アカウント、または Google グループをメンバーとして追加して、アルファ版の機能にアクセスできます。ユーザーが Google グループ ar-trusted-testers@googlegroups.com のメンバーであることが必要です。

  6. メンバーのロールを選択します。メンバーに付与する権限は最小限の権限に留めることを推奨します。

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

gcloud

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

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

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

ここで

  • REPOSITORY はリポジトリの ID です。
  • MEMBER は、バインディングを追加するメンバーです。 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

Terraform を使用したリポジトリのプロビジョニングと、リポジトリの権限の付与については、Terraform との統合をご覧ください。

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

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

公開読み取り専用アクセス権用のリポジトリを構成するには、メンバー allUsers に Artifact Registry 読み取りロールを付与します。

コンソール

  1. Cloud Console で [リポジトリ] ページを開きます。

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

  2. 該当するリポジトリを選択します。

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

  4. [権限] タブで、[メンバーを追加] をクリックします。

  5. [新しいメンバー] 項目に「allUsers」と入力します。

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

gcloud

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

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

ここで

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

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

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

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

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

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

権限の取り消し

リポジトリへのアクセス権を取り消すには、承認済みメンバーのリストからメンバーを削除します。

リポジトリから公開アクセス権を削除するには、allUsers メンバーを削除します。

コンソール

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

  1. Cloud Console で [リポジトリ] ページを開きます。

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

  2. 該当するリポジトリを選択します。

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

  4. [権限] タブで、適切なメンバーを展開します。公開リポジトリを非公開にしている場合は、allUsers メンバーを展開します。

  5. [メンバーを削除] をクリックしてアクセス権を取り消します。

gcloud

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

gcloud projects remove-iam-policy-binding PROJECT --member=MEMBER --role=ROLE
  • PROJECT は、プロジェクト ID です。
  • MEMBER は、バインディングを削除するメンバーです。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 --member=MEMBER --role=ROLE

ここで

  • REPOSITORY はリポジトリの ID です。
  • MEMBER は、バインディングを削除するメンバーです。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-policy-binding my-repo \
 --location=us-central1 --member='user:write@gmail.com' --role='roles/artifactregistry.writer'

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

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

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

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

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

デフォルトでは、Compute Engine のデフォルトのデフォルトサービス アカウントには、同じプロジェクト内のリソースと read-only ストレージ アクセス スコープに対する編集権限があります。サービス アカウントのメールアドレスには、@developer.gserviceaccount.com というサフィックスが付加されています。

編集者権限は通常、書き込み権限を付与するものであるのに対して、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. イメージを push するには、コンテナ以外の形式のリポジトリを操作するか、クラスタから gcloud コマンドを実行して、クラスタを作成する際にサービス アカウントのアクセス スコープを設定する必要があります。

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

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

アクセス スコープの設定

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

gcloud container clusters create CLUSTER-NAME --scopes=SCOPE

ここで

CLUSTER-NAME はクラスタ名です。 SCOPE はニーズに一致するスコープです。

  • Docker リポジトリの場合は、次のいずれかのオプションを選択します。

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

新しいクラスタの作成時に設定できるスコープの詳細については、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 シークレットが定義されます。

カスタム サービス アカウントの構成

カスタム サービス アカウントを ID として使用するクラスタの場合は、Artifact Registry が実行されている Google Cloud プロジェクトからサービス アカウントに必要な権限を付与する必要があります。

次のステップ

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