在 AKS 和 EKS 上啟用 Workload Identity Federation

本主題說明如何在 AKS 和 EKS 平台上，為 Apigee Hybrid 安裝程序啟用 Workload Identity。

總覽

透過工作負載身分聯盟，在 Google Cloud 以外執行的應用程式可使用外部身分提供者的憑證，冒用 Google Cloud Platform 服務帳戶。

使用工作負載身分聯盟可讓應用程式使用外部環境提供的驗證機制，進而提升安全性，並有助於取代服務帳戶金鑰。

如需總覽，請參閱「使用 Workload Identity 聯盟的最佳做法」。

設定 Workload Identity 聯盟

如要搭配 Apigee hybrid 使用 Workload Identity Federation，請先設定叢集，然後將這項功能套用至 Apigee hybrid 安裝。

設定叢集以使用 Workload Identity Federation。

請按照 Google Cloud 的操作說明設定 Kubernetes 適用的工作負載身分聯盟，並進行下列修改：

  • 使用下列指令列出 IAM 服務帳戶和 Kubernetes 服務帳戶：
    • IAM 服務帳戶：您很可能已在使用 create-service-account 工具初次安裝 Apigee hybrid 時建立 IAM 服務帳戶 (也稱為「Google 服務帳戶」)。如要查看 Apigee hybrid 所需的 IAM 服務帳戶清單，請參閱「關於服務帳戶」。

      您可以使用下列指令，查看專案中的 IAM 服務帳戶清單： 

      gcloud iam service-accounts list --project PROJECT_ID
    • Kubernetes 服務帳戶：執行 helm install 或 helm update 指令時，Apigee 混合圖表會為每個元件建立必要的 Kubernetes 服務帳戶。

      您可以使用 kubectl get sa 指令查看叢集中的 Kubernetes 服務帳戶：

      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 服務帳戶都會有一個憑證設定檔。儲存每個憑證設定檔，並儲存為 --credential-source-file 參數輸入的路徑，例如：/var/run/service-account/token。

設定 Apigee Hybrid 以使用 Workload Identity 聯盟

  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 Provider 的允許對象，也就是您在步驟 1 的「部署 Kubernetes 工作負載」下方，憑證設定 JSON 檔案中 .audience 下的值。
    • CREDENTIAL_SOURCE_FILE 是憑證來源檔案的檔案名稱和路徑，Workload Identity Federation 會使用這項資訊取得服務帳戶的憑證。這是您在部署 Kubernetes 工作負載的步驟 1 中，使用 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 密鑰或 Vault 的操作說明。

    憑證檔案

    將 serviceAccountPath 的值替換為憑證來源檔案。這個路徑必須與圖表目錄相關。例如：

    udca:
  serviceAccountPath: fwi/credential-configuration.json

    K8s 密鑰

    1. 建立新的 Kubernetes 密鑰，用於憑證來源檔案。
      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 的值替換為新密鑰。例如：
      udca:
  serviceAccountRef: udca-fwi-secret

    保管箱

    使用憑證來源檔案更新 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 hybrid Helm 參考資料。

如要進一步瞭解 Workload Identity 聯盟和最佳做法，請參閱「使用 Workload Identity 聯盟的最佳做法」。