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

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

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

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

Apigee ハイブリッドは、Kubernetes クラスタ上で動作する各コンポーネントの認証と認可に Google Cloud サービス アカウントを使用します。これらのサービス アカウントは、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 ハイブリッド コンポーネントからアクセス可能なディレクトリに配置します。これらのファイルへのパスを、overrides.yaml の構成で serviceAccountPath および envs[].serviceAccountPaths プロパティを使用して指定します。

例:

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

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

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

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

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

例:

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 プロバイダを使用して、クラスタの ID プロバイダと Google Cloudの間に信頼関係を構築することで、GKE 以外のクラスタが Google Cloud に対して認証できるようになります。初期設定が完了すれば、この方法ではサービス アカウント キー ファイルが不要になります。

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

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

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

overrides.yaml ファイルで gcp.federatedWorkloadIdentity.enabled、gcp.federatedWorkloadIdentity.audience、gcp.federatedWorkloadIdentity.credentialSourceFile の各プロパティを設定することで、Workload Identity 連携を有効にします。

例:

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 ソリューションとなります。この方法は、鍵をファイルとして直接保存するよりも高いセキュリティを提供します。
  • サービス アカウント キー ファイルを直接使用する方法は、初期テストや他の方法が実現できない環境に適しています。ただし、この方法では、手動での鍵管理とローテーションを慎重に行う必要があります。

次のステップ