Apigee Hybrid 中的服務帳戶驗證方法

在 Apigee Hybrid 中選擇服務帳戶驗證方法

Apigee Hybrid 需要服務帳戶，才能與 Google Cloud 服務安全通訊。請為這些服務帳戶選擇符合安全性與作業需求的驗證方法。本指南將簡要說明可用的選項。

瞭解服務帳戶驗證

Apigee Hybrid 會使用 Google Cloud 服務帳戶，驗證及授權 Kubernetes 叢集中執行的元件。這些服務帳戶會存取 Google Cloud 資源，例如 Cloud Storage 儲存空間和 Cloud Logging。每個服務帳戶都需要特定的 Identity and Access Management (IAM) 角色，才能執行其功能。

驗證方式選項

Apigee Hybrid 支援多種服務帳戶驗證方法。每種方法管理服務帳戶金鑰的方式不同，提供的安全性層級和作業複雜度也不同。選取方法時，請考量平台、安全狀態和現有基礎架構。

下表列出可用的驗證方法：

方法 金鑰儲存位置 平台相容性 金鑰管理
Kubernetes Secret Kubernetes 叢集密鑰 任何 Kubernetes 平台 Kubernetes 管理密鑰，手動輪替
服務帳戶 JSON 金鑰檔案 本機檔案系統 任何 Kubernetes 平台 手動輪播和發布
保管箱 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 密鑰中

將服務帳戶金鑰儲存為叢集內的 Kubernetes 密鑰。這個方法會運用 Kubernetes 的內建密鑰管理功能。與直接儲存檔案相比，Kubernetes 密鑰可提供更安全的金鑰管理方式。您仍須手動管理金鑰輪替。

混合式元件會使用 overrides.yaml 檔案中的 serviceAccountRef 和 envs[].serviceAccountRefs 屬性參照這些密鑰。 Kubernetes 會將這些密鑰分配給適當的 Pod。

例如：

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

如要使用這個方法，請參閱「將服務帳戶金鑰儲存在 Kubernetes 密鑰中」。

服務帳戶 JSON 金鑰檔案

這個方法需要為每個服務帳戶建立 JSON 金鑰檔案，並直接將這些檔案儲存在檔案系統中。這種做法可簡化初始設定。不過，您必須確保檔案系統安全無虞。金鑰輪替是手動作業。

將每個服務帳戶的私密金鑰 JSON 檔案放在 Apigee Hybrid 元件可存取的目錄中。在 overrides.yaml 設定中，使用 serviceAccountPath 和 envs[].serviceAccountPaths 屬性參照這些檔案的路徑。

例如：

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

您可以使用 Apigee Hybrid 隨附的 create-service-account 工具，產生及下載服務帳戶金鑰檔案。詳情請參閱 create-service-account 的說明。

在保管箱中儲存服務帳戶金鑰

整合 HashiCorp Vault 來管理服務帳戶金鑰。Vault 提供強大的密鑰管理解決方案，可動態產生密鑰、稽核，以及自動輪換金鑰。您必須設定及維護 Vault 執行個體。

您需要為機構層級和環境層級的元件，分別建立 Vault 密鑰、政策和角色。您可以使用 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

透過 GKE 適用的 Workload Identity Federation，Kubernetes 服務帳戶可以 Google Cloud服務帳戶的身分執行作業。這個方法完全不需要服務帳戶金鑰檔案。而是由 GKE 叢集直接使用Google Cloud IAM 驗證工作負載。GKE 適用的工作負載身分聯盟提供高度安全的自動驗證機制，可簡化金鑰管理作業。這個方法僅適用於 GKE 叢集。

這個方法需要將每個 Kubernetes 服務帳戶繫結至特定 Google Cloud 服務帳戶。安裝 Apigee Hybrid Helm 資訊圖表時，Apigee Hybrid 安裝程序會建立專為安裝作業使用的 Kubernetes 服務帳戶。使用每個圖表的 --dry-run 標記執行 helm install 或 helm upgrade 指令時，輸出內容會包含將 Kubernetes 服務帳戶繫結至該圖表中特定 Apigee Hybrid 元件的 Google Cloud 服務帳戶的指令。

您可以在 overrides.yaml 檔案中，使用 gcp.workloadIdentity.enabled 屬性啟用 Workload Identity Federation for GKE。

例如：

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

請參閱「啟用 GKE 適用的工作負載身分聯盟」。

在 GKE 以外的平台使用 Workload Identity 聯盟

Workload Identity Federation 可將 GKE 適用的 Workload Identity Federation 優勢，擴展至 Google Cloud以外執行的 Kubernetes 叢集，例如 Azure Kubernetes Service (AKS)、Amazon Elastic Kubernetes Service (EKS) 或 OpenShift。這個方法可讓非 GKE 叢集透過叢集的 OIDC 提供者向 Google Cloud 進行驗證，藉此在叢集的 IDP 與 Google Cloud之間建立信任關係。完成初始設定後，這個方法就不需要服務帳戶金鑰檔案。

您可以搭配下列項目使用 Workload Identity 聯盟：

  • 憑證設定檔 (取代服務帳戶金鑰檔案)
  • Kubernetes Secret
  • 保管箱

如要使用 Workload Identity Federation，請為每個 Google Cloud 服務帳戶建立憑證設定檔。如果您使用這些方法，可以改用這些檔案，或設定 Kubernetes 密鑰或 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 Federation」。

選擇驗證方式

根據部署環境和安全性需求選取驗證方式。

  • 對於 GKE 部署作業，Workload Identity Federation for GKE 提供安全且簡化的方法。這樣就不需要直接管理服務帳戶金鑰檔案。
  • 對於非 GKE Kubernetes 部署作業 (AKS、EKS、OpenShift)，Workload Identity Federation 提供類似的無金鑰驗證體驗。建議在這些環境中使用此方法。
  • 如果無法使用 GKE 適用的 Workload Identity Federation 或 Workload Identity Federation， 建議使用 Vault 集中管理及自動化處理金鑰。
  • 如要簡化部署作業，或是沒有 Vault 設定，將金鑰儲存在 Kubernetes 密鑰中，即可使用 Kubernetes 原生解決方案。相較於直接儲存檔案，這種方法更安全。
  • 直接使用服務帳戶金鑰檔案適合用於初步測試，或無法使用其他方法的環境。不過，這種方法需要謹慎地手動管理及輪替金鑰。

後續步驟