Apigee ハイブリッドのサービス アカウント認証方法

Apigee ハイブリッドでサービス アカウントの認証方法を選択する

Apigee ハイブリッドでは、 Google Cloud サービスとの安全な通信にサービス アカウントが必要です。セキュリティと運用の要件に沿った、これらのサービス アカウントの認証方法を選択します。このガイドでは、利用可能なオプションの概要を簡単に説明します。

サービス アカウント認証について

Apigee ハイブリッドは、 Google Cloud サービス アカウントを使用して、Kubernetes クラスタで実行されているコンポーネントを認証し、承認します。これらのサービス アカウントは、Cloud Storage バケットや Cloud Logging などのリソースにアクセスします。 Google Cloud 各サービス アカウントには、機能を実行するための特定の Identity and Access Management（IAM）ロールが必要です。

認証方法のオプション

Apigee ハイブリッドは、サービス アカウントの認証に複数の方法をサポートしています。各メソッドはサービス アカウント キーを異なる方法で管理し、さまざまなレベルのセキュリティと運用上の複雑さを提供します。方法を選択する際は、プラットフォーム、セキュリティ ポスチャー、既存のインフラストラクチャを考慮してください。

次の表に、使用可能な認証方法の概要を示します。

メソッド 鍵の保存場所 プラットフォームの互換性 鍵管理
Kubernetes Secret Kubernetes クラスタのシークレット 任意の Kubernetes プラットフォーム Kubernetes が Secret を管理し、手動でローテーションする
サービス アカウントの JSON キーファイル ローカル ファイル システム 任意の Kubernetes プラットフォーム 手動ローテーションと配布
Vault HashiCorp Vault 任意の Kubernetes プラットフォーム Vault がシークレットを管理し、手動でローテーションする
Workload Identity Federation for GKE Google Cloud IAM Google Kubernetes Engine（GKE） Google Cloud が管理するため、鍵ファイルは不要です。
他のプラットフォームでの Workload Identity 連携 Google Cloud IAM AKS、EKS、OpenShift、その他の Kubernetes プラットフォーム Google Cloud が管理するため、鍵ファイルは不要です。

サービス アカウント キーを Kubernetes Secret に保存する

サービス アカウント キーをクラスタ内の Kubernetes Secret として保存します。この方法は、Kubernetes の組み込みのシークレット管理機能を活用します。Kubernetes Secret は、直接ファイル ストレージよりも安全な鍵管理方法を提供します。鍵のローテーションは手動で管理します。

ハイブリッド コンポーネントは、overrides.yaml ファイルの serviceAccountRef プロパティと envs[].serviceAccountRefs プロパティを使用して、これらのシークレットを参照します。Kubernetes は、これらのシークレットの適切な Pod への配布を管理します。

次に例を示します。

logger:
  serviceAccountRef: "my-project-apigee-logger-key"

この方法を使用するには、Kubernetes Secret にサービス アカウント キーを保存するをご覧ください。

サービス アカウントの JSON キーファイル

この方法では、各サービス アカウントの JSON キーファイルを作成し、これらのファイルをファイル システムに直接保存します。このアプローチは、初期設定を簡素化します。ただし、ファイル システムのセキュリティを確保する必要があります。鍵のローテーションは手動です。

各サービス アカウントの秘密鍵の JSON ファイルを、Apigee ハイブリッド コンポーネントからアクセス可能なディレクトリに配置します。serviceAccountPath プロパティと envs[].serviceAccountPaths プロパティを使用して、overrides.yaml 構成でこれらのファイルのパスを参照します。

次に例を示します。

logger:
  serviceAccountPath: "my-project-apigee-logger.json"

サービス アカウント キーファイルは、Apigee ハイブリッドに付属の create-service-account ツールを使用して生成してダウンロードできます。詳細については、create-service-account をご覧ください。

サービス アカウント キーを Vault に保存する

HashiCorp Vault を統合して、サービス アカウント キーを管理します。Vault は、動的シークレットの生成、監査、自動キーローテーションなどの機能を提供する、シークレット管理のための堅牢なソリューションです。Vault インスタンスの設定とメンテナンスが必要です。

組織レベルと環境レベルのコンポーネント用に、別々の Vault の Secret、ポリシー、ロールを作成する必要があります。これらのシークレットは、serviceAccountSecretProviderClass プロパティと envs[].serviceAccountSecretProviderClass プロパティを使用して、overrides.yaml 構成で参照します。

次に例を示します。

serviceAccountSecretProviderClass: apigee-orgsakeys-spc

envs:
- name: my-env
  serviceAccountSecretProviderClass: apigee-envsakeys-my-env-spc

Vault にサービス アカウント キーを保存するをご覧ください。

Workload Identity Federation for GKE

Workload Identity Federation for GKE を使用すると、Kubernetes サービス アカウントが Google Cloudサービス アカウントとして機能します。この方法では、サービス アカウント キーファイルが完全に不要になります。代わりに、GKE クラスタはGoogle Cloud IAM を使用してワークロードを直接認証します。Workload Identity Federation for GKE は、安全性の高い自動認証メカニズムを提供し、鍵管理を簡素化します。この方法は、GKE クラスタに固有のものです。

この方法では、各 Kubernetes サービス アカウントを特定の Google Cloud サービス アカウントにバインドする必要があります。Apigee ハイブリッド インストール プロセスでは、Apigee ハイブリッド Helm チャートをインストールするときに、インストールに固有の Kubernetes サービス アカウントが作成されます。各チャートに対して --dry-run フラグを指定して helm install または helm upgrade コマンドを実行すると、出力には、Kubernetes サービス アカウントをそのチャート内の特定の Apigee ハイブリッド コンポーネントの Google Cloud サービス アカウントにバインドするコマンドが含まれます。

overrides.yaml ファイルで gcp.workloadIdentity.enabled プロパティを使用して、Workload Identity Federation for GKE を有効にします。

次に例を示します。

gcp:
  projectID: my-project
  region: us-west1
  workloadIdentity:
    enabled: true

Workload Identity Federation for GKE を有効にするをご覧ください。

GKE 以外のプラットフォームでの Workload Identity 連携

Workload Identity 連携は、Workload Identity Federation for GKE のメリットを、 Google Cloudの外部で実行されている Kubernetes クラスタ（Azure Kubernetes Service（AKS）、Amazon Elastic Kubernetes Service（EKS）、OpenShift など）に拡張します。この方法では、クラスタの OIDC プロバイダを使用して Google Cloud を認証し、クラスタの ID プロバイダと Google Cloudの間に信頼関係を構成します。この方法では、初期設定後にサービス アカウント キーファイルが不要になります。

Workload Identity 連携は、次のものと組み合わせて使用できます。

  • 認証情報構成ファイル（サービス アカウント キーファイルの代わり）
  • Kubernetes Secret
  • Vault

Workload Identity 連携を使用するには、各 Google Cloud サービス アカウントの認証情報構成ファイルを作成します。これらのファイルは、サービス アカウント キー ファイルの代わりに使用するか、これらの方法を使用している場合は Kubernetes Secret または Vault を設定するために使用します。

Workload Identity 連携は、overrides.yaml ファイルで gcp.federatedWorkloadIdentity.enabled、gcp.federatedWorkloadIdentity.audience、gcp.federatedWorkloadIdentity.credentialSourceFile の各プロパティを使用して有効にします。

次に例を示します。

gcp:
  projectID: my-project
  region: us-west1
  federatedWorkloadIdentity:
    enabled: true
    audience: "//iam.googleapis.com/projects/123123123123/locations/global/workloadIdentityPools/my-wi-pool/providers/my-wi-provider"
    credentialSourceFile: "/var/run/service-account/token"

Workload Identity 連携を有効にするをご覧ください。

認証方法を選択する

デプロイ環境とセキュリティ要件に基づいて、認証方法を選択します。

  • GKE デプロイの場合、Workload Identity Federation for GKE は安全で効率的なアプローチを提供します。これにより、サービス アカウント キーファイルを直接管理する必要がなくなります。
  • GKE 以外の Kubernetes デプロイ（AKS、EKS、OpenShift）の場合、Workload Identity 連携は同様のキーレス認証エクスペリエンスを提供します。この方法は、このような環境におすすめです。
  • Workload Identity Federation for GKE または Workload Identity 連携がオプションでない場合は、Vault を使用して鍵の集中管理と自動化を行うことを検討してください。
  • デプロイが簡単な場合や、Vault の設定がない場合は、Kubernetes Secret に鍵を保存すると、ネイティブの Kubernetes ソリューションが提供されます。この方法は、直接ファイル ストレージよりもセキュリティが強化されています。
  • 直接サービス アカウントの鍵ファイルは、初期テストや他の方法が実現できない環境に適しています。ただし、この方法では、鍵の手動管理とローテーションを慎重に行う必要があります。

次のステップ