與任何主體一樣,服務帳戶可以向 Google 驗證自身身分、取得 OAuth 2.0 存取權杖,以及呼叫 Google API。不過,服務帳戶的程序與使用者不同。
服務帳戶會透過下列其中一種方式進行驗證:
短期服務帳戶憑證
以服務帳戶身分進行驗證最安全的方式,就是取得服務帳戶的短期憑證,也就是 OAuth 2.0 存取權杖。根據預設,這些權杖會在 1 小時後失效。
短期服務帳戶憑證適用的情境如下:您必須將有限的資源存取權授予信任的服務帳戶。相較於長期憑證 (例如服務帳戶金鑰),短期憑證的風險也較低。
在許多情況下,系統會自動取得這些憑證,您不需要自行建立或管理。例如:
- 如果您執行 Google Cloud CLI 指令,並加入
--impersonate-service-account
旗標,則 gcloud CLI 會為服務帳戶建立短期憑證,並使用這些憑證執行指令。 如果您將服務帳戶附加至 Compute Engine 虛擬機器 (VM) 執行個體,該執行個體上的工作負載就能使用 Cloud 用戶端程式庫存取 Google Cloud 服務。Cloud 用戶端程式庫會使用應用程式預設憑證 (ADC),取得服務帳戶的短期憑證。
如要瞭解這項程序的詳情,請參閱「使用服務帳戶憑證驗證應用程式」。
如果您已設定工作負載身分聯合,Cloud 用戶端程式庫就能使用身分識別提供者的憑證,產生短期服務帳戶憑證。
您也可以使用 Service Account Credentials API 手動建立短期憑證。舉例來說,您可以建立服務,為使用者提供服務帳戶的短期憑證,讓他們暫時存取 Google Cloud 資源。
Service Account Credentials API 可建立下列類型的憑證:
- OAuth 2.0 存取憑證
- OpenID Connect (OIDC) ID 權杖
- 自行簽署的 JSON Web Token (JWT)
- 自行簽署的二進位大型物件
詳情請參閱「建立短期服務帳戶憑證」。
解讀稽核記錄
Cloud 稽核記錄可協助您瞭解 Google Cloud 資源中「從事活動的人員、內容、地點及時間」。
使用短期憑證模擬服務帳戶時,大多數Google Cloud 服務都會建立記錄項目,顯示下列身分:
- 短期憑證模擬的服務帳戶
- 建立短期憑證的身分
您可以透過這些記錄項目,找出建立短期憑證的主體,以及主體模擬的服務帳戶。
如需顯示服務帳戶模擬作業的稽核記錄項目範例,請參閱模擬服務帳戶以存取 Google Cloud。
冒用自己身分
自我模擬是指使用服務帳戶本身的憑證,為該服務帳戶產生新憑證。
Service Account Credentials API 禁止下列類型的自我模擬:
使用服務帳戶的短期憑證,為服務帳戶產生新的存取權杖。
自行簽署的 JSON Web Token (JWT) 是這項規則的例外情況,您可以為服務帳戶使用自行簽署的 JWT,為該服務帳戶產生新的存取權杖。
使用服務帳戶的短期憑證簽署二進位物件 (BLOB) 或 JWT,可用於呼叫下列 API:
Google Cloud 禁止這類自我冒用行為,因為惡意行為人可以藉此無限期重新整理遭竊的權杖。
如果您嘗試以禁止的方式進行自我模擬,可能會遇到下列錯誤:
FAILED_PRECONDITION: You can't create a token for the same service account that you used to authenticate the request.
如果遇到這個錯誤,請嘗試使用其他憑證,為服務帳戶產生新的短期憑證,例如您的使用者憑證或其他服務帳戶的憑證。
服務帳戶金鑰
每個服務帳戶都與公開/私密 RSA 金鑰組相關聯。Service Account Credentials API 會使用這組內部金鑰,建立短期服務帳戶憑證,並簽署 Blob 和 JSON Web Token (JWT)。這組金鑰稱為「Google-owned and managed key 配對」。
此外,您還可以建立多組公開/私密 RSA 金鑰組 (稱為使用者代管金鑰組),並使用私密金鑰向 Google API 進行驗證。這個私密金鑰又稱為「服務帳戶金鑰」。
Google-owned and managed key 組
Google-owned and managed key 配對是由服務帳戶憑證 API,以及 App Engine 和 Compute Engine 等服務使用,用來為服務帳戶產生短期憑證。 Google Cloud
Google-owned and managed keys 定期輪替用於簽署的金鑰,並遵循安全性最佳做法。輪替程序是隨機的;新金鑰的使用會隨著金鑰生命週期的演進逐漸增加或減少。
Google-owned and managed key 金鑰配對中的私密金鑰一律以信託形式儲存,您永遠無法直接存取。
Google-owned and managed key 金鑰組中的公開金鑰可公開存取,因此任何人都能驗證以私密金鑰建立的簽章。您可以透過多種格式存取公開金鑰:
- X.509 憑證:
https://www.googleapis.com/service_accounts/v1/metadata/x509/SERVICE_ACCOUNT_EMAIL
- JSON Web Key (JWK):
https://www.googleapis.com/service_accounts/v1/jwk/SERVICE_ACCOUNT_EMAIL
- 原始格式:
https://www.googleapis.com/service_accounts/v1/metadata/raw/SERVICE_ACCOUNT_EMAIL
如果您下載並快取公開金鑰,建議快取最多 24 小時,確保您隨時可以存取目前的金鑰。無論何時擷取公開金鑰,金鑰在擷取後至少 24 小時內都有效。
使用者管理的金鑰組
您可以為服務帳戶建立使用者管理金鑰組,然後使用每個金鑰組的私密金鑰向 Google API 進行驗證。這個私密金鑰又稱為服務帳戶金鑰。
Cloud 用戶端程式庫可以使用服務帳戶金鑰,自動取得 OAuth 2.0 存取權杖。您也可以使用服務帳戶金鑰手動簽署 JWT,然後使用已簽署的 JWT 要求存取權杖。詳情請參閱「為伺服器對伺服器應用程式採用 OAuth 2.0」。
每個服務帳戶最多可有 10 個服務帳戶金鑰。Google 只會儲存使用者管理金鑰組的公開部分。
建立服務帳戶專用的使用者管理金鑰組有幾種方式:
- 使用 IAM API 自動建立使用者代管金鑰組。Google 會產生公開/私密金鑰組,只儲存公開金鑰,並將私密金鑰傳回給您。
- 自行建立使用者管理的金鑰組,然後只上傳公開金鑰。Google 絕不會看到私密金鑰。
使用者代管的金鑰是功能非常強大的憑證。如要限制使用使用者管理的金鑰,您可以在機構、專案或資料夾中強制執行下列機構政策限制:
constraints/iam.disableServiceAccountKeyCreation
:禁止主體建立使用者代管的服務帳戶金鑰。constraints/iam.disableServiceAccountKeyUpload
:禁止主體上傳服務帳戶的公開金鑰。
如果您因為使用 Workload Identity 聯盟而強制執行這些限制,請考慮使用 Workload Identity 聯盟的機構政策限制,指定允許的識別資訊提供者。
使用者管理金鑰的到期時間
根據預設,建立使用者管理的服務帳戶金鑰時,金鑰永遠不會過期。如要變更這項預設值,請為專案、資料夾或機構中所有新建立的金鑰設定到期時間。有效時間是指新建立的金鑰有效的小時數。
需要暫時存取需要服務帳戶金鑰的系統時,請使用有效時間。舉例來說,在執行下列操作時,請使用到期時間:
- 在非正式環境中開發程式碼,以供只能使用服務帳戶金鑰驗證的應用程式使用
- 使用只能透過服務帳戶金鑰驗證的第三方工具
在下列情況請避免使用有效期限:
- 正式環境工作負載。在正式環境中,過期的服務帳戶金鑰可能會導致意外中斷。請改用不會過期的金鑰,並透過金鑰輪替管理金鑰生命週期。
- 需要永久存取權的非正式環境工作負載,例如持續整合 (CI) 管道。
- 金鑰輪替系統,可防止金鑰在指定時間後繼續使用。如要瞭解建議的金鑰輪替策略,請參閱服務帳戶金鑰輪替。
為避免服務中斷,除非constraints/iam.disableServiceAccountKeyCreation
機構政策限制已實施一段時間,否則建議不要設定到期時間。設定到期時間時,也必須停止強制執行 constraints/iam.disableServiceAccountKeyCreation
限制。如要進一步瞭解這項限制,請參閱「限制服務帳戶金鑰的生命週期」。
如要設定有效期限,請按照下列步驟操作:
- 找出要為服務帳戶金鑰設定到期時間的專案、資料夾或機構。
- 新增機構政策,強制執行
constraints/iam.serviceAccountKeyExpiryHours
限制。為專案、資料夾或機構強制執行這項限制後,該上層資源內所有新建立的服務帳戶金鑰都會套用有效期限。現有金鑰不會受到影響。
有效時間以小時為單位。最佳做法是使用較短的到期時間,例如 8 小時、24 小時 (1 天) 或 168 小時 (7 天)。設定較短的到期時間,有助於確保團隊擁有經過充分測試的金鑰更新程序。請先設定符合需求的最短到期時間,只有在必要時才延長。