AKS と EKS で Workload Identity 連携を有効にする

このトピックでは、AKS プラットフォームと EKS プラットフォームで Apigee ハイブリッドのインストール用に Workload Identity を有効にする方法について説明します。

概要

Workload Identity 連携を使用すると、Google Cloud の外部で実行されているアプリケーションが、外部 ID プロバイダの認証情報を使用して Google Cloud Platform サービス アカウントの権限を借用できます。

Workload Identity 連携を使用すると、外部環境の認証メカニズムをアプリケーションで使用できるようになり、セキュリティを強化できます。また、サービス アカウント キーを置き換えることもできます。

概要については、Workload Identity 連携の使用に関するベスト プラクティスをご覧ください。

Workload Identity 連携を設定する

Apigee ハイブリッドで Workload Identity 連携を使用するには、まずクラスタを構成してから、Apigee ハイブリッド インストールに機能を適用します。

Workload Identity 連携を使用するようにクラスタを構成します。

Google Cloud の手順に沿って Kubernetes 用 Workload Identity 連携を構成するの手順を実施します。ただし、次の変更を行います。

• 次のコマンドを使用して、IAM サービス アカウントと Kubernetes サービス アカウントを一覧取得します。
  • IAM サービス アカウント: 通常、Apigee ハイブリッドの初回インストール時に create-service-account ツールを使用して IAM サービス アカウント（Google サービス アカウント）を作成しています。Apigee ハイブリッドに必要な IAM サービス アカウントの一覧については、サービス アカウントについてをご覧ください。

    プロジェクト内の IAM サービス アカウントの一覧を表示するには、次のコマンドを使用します。

    gcloud iam service-accounts list --project PROJECT_ID

  • Kubernetes サービス アカウント: Apigee ハイブリッド チャートは、helm install または helm update コマンドを実行するときに、コンポーネントごとに必要な Kubernetes サービス アカウントを作成します。

    クラスタ内の Kubernetes サービス アカウントは、kubectl get sa コマンドを使用して確認できます。

    kubectl get sa -n APIGEE_NAMESPACE
    kubectl get sa -n apigee-system

• Workload Identity 連携の構成の手順で、作成された Workload Identity プールとプロバイダのデフォルトの対象は次のとおりです。このデフォルトを使用するか、カスタムの想定オーディエンスを設定します。後で使用できるように、この値は保存しておいてください。

  https://iam.googleapis.com/projects/PROJECT_NUM/locations/global/workloadIdentityPools/POOL_ID/providers/PROVIDER_ID

• 「Kubernetes ワークロードをデプロイする」のステップ 1 で停止します。Google サービス アカウントごとに 1 つの認証情報構成ファイルがあります。各認証情報構成ファイルを保存し、--credential-source-file パラメータに入力したパス（/var/run/service-account/token など）を保存します。

Workload Identity 連携を使用するように Apigee ハイブリッドを構成する

1. 認証情報のソースファイルと出力ファイル（credential-configuration.json）を次のチャート ディレクトリにコピーします。これらの値は、ステップ 1 の「Kubernetes ワークロードをデプロイする」で指定した値です。
   • apigee-datastore/
   • apigee-env
   • apigee-org/
   • apigee-telemetry/
2. クラスタのオーバーライド ファイルに次のグローバルな変更を加えます。

   gcp:
     workloadIdentity:
       enabled: false # must be set to false to use Workload Identity Federation
     federatedWorkloadIdentity:
       enabled: true
       audience: "AUDIENCE"
       credentialSourceFile: "CREDENTIAL_SOURCE_FILE"
   

   ここで

   • AUDIENCE は、Workload Identity プロバイダの許可されたオーディエンスです。これは、ステップ 1 の「Kubernetes ワークロードをデプロイする」で構成した認証情報構成 JSON ファイルの .audience の値です。
   • CREDENTIAL_SOURCE_FILE は、Workload Identity 連携でサービス アカウントの認証情報を取得するために使用される認証情報ソースファイルのファイル名とパスです。これは、ステップ 1 の「Kubernetes ワークロードをデプロイする」で、create-cred-config コマンドを使用して Workload Identity 連携を構成するときに credential-source-file に指定する値です。次に例を示します。

   例:

   gcp:
     workloadIdentity:
       enabled: false
     federatedWorkloadIdentity:
       enabled: true
       audience: "//iam.googleapis.com/projects/123456789012/locations/global/workloadIdentityPools/aws-pool/providers/aws-provider"
       credentialSourceFile: "/var/run/service-account/token"
   

3. Workload Identity 連携を使用して、各コンポーネントのオーバーライドを構成します。インストールに応じて、証明書ファイル、Kubernetes Secret、Vault の手順を選択します。

   証明書ファイル

   serviceAccountPath の値は、認証情報のソースファイルに置き換えます。これは、チャート ディレクトリからの相対パスにする必要があります。例:

   udca:
     serviceAccountPath: fwi/credential-configuration.json
   

   K8s Secret

   1. 認証情報ソースファイルを使用して新しい Kubernetes Secret を作成します。

      kubectl create secret -n apigee generic SECRET_NAME --from-file="client_secret.json=CREDENTIAL_CONFIGURATION_FILE"

      例:

      kubectl create secret -n apigee generic udca-fwi-secret --from-file="client_secret.json=./fwi/credential-configuration.json"

   2. serviceAccountRef の値を新しい Secret に置き換えます。次に例を示します。

      udca:
        serviceAccountRef: udca-fwi-secret
      

   Vault

   Vault のサービス アカウント キー SAKEY を、認証情報ソースファイルで更新します。たとえば、UDCA の場合（手順はすべてのコンポーネントで同様です）は次のようにします。

   SAKEY=$(cat ./fwi/credential-configuration.json); kubectl -n apigee exec vault-0 -- vault kv patch secret/apigee/orgsakeys udca="$SAKEY"

4. helm update コマンドを使用して、影響を受ける各コンポーネントに変更を適用します。

   このクラスタで初めて Vault を使用する場合は、apigee-operator チャートを更新します。

   helm upgrade operator apigee-operator/ \
     --namespace apigee-system \
     --atomic \
     -f overrides.yaml
   

   影響を受ける残りのチャートを次の順序で更新します。

   helm upgrade datastore apigee-datastore/ \
     --namespace apigee \
     --atomic \
     -f overrides.yaml
   

   helm upgrade telemetry apigee-telemetry/ \
     --namespace apigee \
     --atomic \
     -f overrides.yaml
   

   helm upgrade $ORG_NAME apigee-org/ \
     --namespace apigee \
     --atomic \
     -f overrides.yaml
   

   環境ごとに apigee-env チャートを更新し、毎回 ENV_NAME を置き換えます。

   helm upgrade $ENV_NAME apigee-env/ \
     --namespace apigee \
     --atomic \
     --set env=$ENV_NAME \
     -f overrides.yaml
   

   コンポーネントと対応するチャートのリストについては、Apigee ハイブリッド Helm リファレンスをご覧ください。

Workload Identity 連携とベスト プラクティスの詳細については、Workload Identity 連携の使用に関するベスト プラクティスをご覧ください。