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 連携を構成するの手順を実施します。ただし、次の変更を行います。

  1. Workload Identity 連携の構成の手順で、作成された Workload Identity プールとプロバイダのデフォルトの対象は次のとおりです。このデフォルトを使用するか、カスタムの想定オーディエンスを設定します。後で使用できるように、この値は保存しておいてください。
    https://iam.googleapis.com/projects/PROJECT_NUM/locations/global/workloadIdentityPools/POOL_ID/providers/PROVIDER_ID
  2. 必要なサービス アカウントはすでに作成されているため、サービス アカウントのペアを作成するの手順は必要ありません。
    • 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
  3. 「Kubernetes ワークロードをデプロイする」のステップ 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_NAMESPACE 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_NAMESPACE exec vault-0 -- vault kv patch secret/apigee/orgsakeys udca="$SAKEY"
  4. helm update コマンドを使用して、影響を受ける各コンポーネントに変更を適用します。

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

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

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

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

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

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

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

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

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

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