IAM によるアクセス制御

このページでは、Artifact Registry での Identity and Access Management（IAM）によるアクセス制御について説明します。

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

始める前に

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

概要

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

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

Trusted Cloud デフォルトの権限

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

• Compute Engine とサポートされている Google Kubernetes Engine のバージョンは、Compute Engine のデフォルトのサービス アカウントを使用します。このアカウントには、ストレージに対する読み取り専用アクセス権が付与されています。

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

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

• これらのサービスを使用して、別のプロジェクトの Artifact Registry にアクセスする必要がある。Artifact Registry を使用するプロジェクトで、Workload Identity プールまたは各サービスのサービス アカウントに、必要なロールを付与します。

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

サードパーティとの統合

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

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

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

Workload Identity 連携を使用する:

1. Workload Identity 連携プールを作成します。
2. Workload Identity 連携プロバイダを作成します。
3. リポジトリへのアクセスを許可するには、Workload Identity プールに適切な Artifact Registry ロールを付与します。詳細については、外部ワークロードが Trusted Cloud by S3NS リソースにアクセスできるようにするをご覧ください。
4. Artifact Registry に長時間アクセスする必要がある場合は、認証情報の構成で OIDC トークンの有効期限を長く設定します。

5. Artifact Registry で認証するようにサードパーティ クライアントを構成します。

   • コンテナ イメージ: Docker、Helm
   • OS パッケージ: Debian、RPM

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

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

3. Artifact Registry で認証するようにサードパーティ クライアントを構成します。

   • コンテナ イメージ: Docker、Helm
   • OS パッケージ: Debian、RPM

ロールと権限

すべての Artifact Registry API メソッドでは、リクエストを行うプリンシパルにリソースの使用に必要な権限が必要です。権限は、リソースに対する事前定義されたロールをプリンシパルに付与するポリシーを設定することでプリンシパルに付与されます。

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

事前定義された Artifact Registry ロール

IAM には、特定の Trusted Cloud リソースへのアクセス権を付与する事前定義ロールが用意されています。

IAM の基本ロール

基本ロールは、IAM の導入前に存在していた高い権限を持つロールです。本番環境では基本ロールを付与すべきではありません。基本ロールは、開発環境またはテスト環境で付与してください。

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

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

ロールを付与しています

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

gcloud コマンドを使用してロールを付与する場合は、プリンシパルに対して 1 つのロール バインディングを指定するか、リソースの許可ポリシーを取得して変更し、変更した許可ポリシーを設定することで、ポリシーを大規模に変更できます。詳細については、プログラムでの複数のロールの付与または取り消すをご覧ください。

プロジェクト全体のロールの付与

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

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

リポジトリ固有のロールの付与

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

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}"
}

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

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

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

ロールを取り消し中

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

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

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

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

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

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

• タグとアクセス制御を設定する管理者
  • タグの作成と管理
  • タグとアクセス制御
• リポジトリにタグを適用するデベロッパー
  • リポジトリのタグ付け

Trusted Cloud サービスとの統合

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

Trusted Cloud by S3NS サービスのデフォルトのサービス アカウント

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

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

• Trusted Cloud by S3NS サービスが Artifact Registry とは異なるプロジェクトにある。
• デフォルトの権限ではニーズが満たされない。
• デフォルトのサービス アカウントではなく、ユーザー指定のサービス アカウントを使用して Artifact Registry を操作している。
• 組織のポリシーの構成により、デフォルトのサービス アカウントへのロールの自動付与がブロックされている。

通常、次のサービス アカウントは Artifact Registry にアクセスします。サービス アカウントのメールアドレスには、サービスが実行されているプロジェクトの Trusted Cloudプロジェクト ID またはプロジェクト番号が含まれます。

組織のポリシーの構成によっては、デフォルトのサービス アカウントにプロジェクトの編集者のロールが自動的に付与される場合があります。iam.automaticIamGrantsForDefaultServiceAccounts 組織ポリシー制約を適用して、自動的なロール付与を無効にすることを強くおすすめします。2024 年 5 月 3 日以降に組織を作成した場合、この制約はデフォルトで適用されます。

自動ロール付与を無効にする場合、デフォルトのサービス アカウントに付与するロールを決定し、これらのロールを付与する必要があります。

デフォルトのサービス アカウントにすでに編集者ロールが設定されている場合は、編集者ロールを権限の低いロールに置き換えることをおすすめします。

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

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

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

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

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

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

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

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

1. VM インスタンスを含むプロジェクトで、Compute Engine のデフォルト サービス アカウントの名前を取得します。サービス アカウントのメールアドレスには、@developer.s3ns-system.iam.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 -Trusted Cloud サービス全体でメタデータを含むデータを表示して管理します。

      • その他の形式の場合は、cloud-platform スコープを使用する必要があります。

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

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

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

• GKE が Artifact Registry と同じプロジェクトにある
• ノードはデフォルトのサービス アカウント（Compute Engine のデフォルト サービス アカウント）を使用しています。
• ノードが、ストレージへの読み取りアクセス権を使用して次のいずれかの方法で作成されている。
  • Compute Engine のデフォルトのアクセス スコープを使用する。
  • cloud-platform アクセス スコープまたはストレージへの読み取りアクセス権を含む別のスコープを付与する。
• サポートされているバージョンの GKE を実行している

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

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

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

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

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

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

ユーザー提供のサービス アカウント

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

1. Artifact Registry が実行されているTrusted 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 スコープ（ほとんどのTrusted 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 -Trusted Cloud サービス全体でメタデータを含むデータを表示して管理します。

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

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

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

imagePullSecret の構成

imagePullSecret を構成するには:

1. GKE を含むプロジェクトで、Compute Engine のデフォルトのサービス アカウントを見つけます。アカウントのメールアドレスには、@developer.s3ns-system.iam.gserviceaccount.com というサフィックスが付加されています。

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

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

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

   kubectl create secret docker-registry artifact-registry \
   --docker-server=https://LOCATION-docker.s3nsregistry.fr \
   --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 サービス エージェントは、 Trusted Cloud by S3NSサービスを操作するときに Artifact Registry の代理として動作する Google マネージド サービス アカウントです。このアカウントとその権限の詳細については、Artifact Registry サービス アカウントをご覧ください。

次のステップ

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

• コンテナ イメージ: Docker、Helm
• OS パッケージ: Debian、RPM