瞭解服務帳戶

背景資訊

服務帳戶是一種特殊類型的 Google 帳戶,屬於您的應用程式或虛擬機器 (VM),而不屬於個別使用者。您的應用程式以服務帳戶的身分以呼叫 Google API,如此一來使用者即不會直接參與其中。服務帳戶可能擁有零個或多個服務帳戶金鑰組,以用於向 Google 進行驗證。

當您確定需要服務帳戶時,可以試問自己以下問題,有助於瞭解您對服務帳戶的使用方式:

  • 服務帳戶可以存取什麼資源?
  • 服務帳戶需要什麼權限?
  • 取得服務帳戶身分的程式碼要在哪裡執行:Google Cloud Platform 或是內部部署?

請利用以下的流程圖找到上述問題的答案:

服務帳戶流程圖

IAM 服務帳戶的其中一項特色是您可以將服務帳戶視為資源身分。

將服務帳戶視為身分時,您可以將角色授予服務帳戶,使服務帳戶能夠存取資源 (例如專案)。

將服務帳戶視為資源時,您可以向使用者授予存取服務帳戶的權限。您可以向使用者授予擁有者、編輯者、檢視者,或存取服務帳戶的服務帳戶使用者角色。

向服務帳戶授予存取權限

向服務帳戶授予對資源的存取權,與向任何其他身分授予存取權類似。舉例來說,如果您在 Google Compute Engine 上執行應用程式,且希望應用程式「只」具備在 Google Cloud Storage 中建立物件的權限。您可以為應用程式建立服務帳戶,然後授予 Storage 物件建立者角色。下列圖表說明了本範例:

服務帳戶流程圖

瞭解將角色授予服務帳戶

以服務帳戶進行作業

假設您有長期運作的工作,而您的員工擁有啟動工作的權限。但是您不希望當最後一位啟動工作的員工離開公司後,工作遭到終止。

解決這個問題的方法是建立一個服務帳戶來啟動及停止工作。透過以下步驟進行即可完成:

  1. 建立服務帳戶

  2. 向需要工作啟動權限的員工,授予服務帳戶的服務帳戶使用者 (iam.serviceAccountUser) 角色。在本情境中,服務為資源。

  3. 向同一群員工授予 Compute 執行個體管理員 (roles/compute.instanceAdmin.v1) 角色。

  4. 現在,員工可以建立執行服務帳戶的 Compute Engine 執行個體,與執行個體連結,並使用服務帳戶啟動工作。例如:

    gcloud compute instances create my-instance --scopes=cloud-platform \
    --service-account=my-service-account@test9q.iam.gserviceaccount.com \
    --zone=us-central1-a
    

如需詳細資訊,請參閱 serviceAccountUser 角色一節。

將資料遷移到 Google Cloud Platform

假設您使用其他的雲端供應商服務處理部分資料,而想要將處理後的資料轉移到 Google Cloud Platform,可以藉由外部雲端服務虛擬機器中的服務帳戶,將資料推送到 Google Cloud Platform。如要進行這項作業,您必須在建立服務帳戶時,建立並下載服務帳戶金鑰,然後透過外部程序使用金鑰來呼叫 Cloud Platform API。

追蹤服務帳戶

隨著時間過去,您會建立越來越多的服務帳戶,可能會導致您不記得服務帳戶的用途。

查看服務帳戶的顯示名稱是個不錯的方法,可以取得更多服務帳戶的相關資訊,像是帳戶用途或是帳戶聯絡人等。對於新服務帳戶,您可以在建立帳戶時填入顯示名稱。對於現有的服務帳務,則可透過 serviceAccounts.update() 方法修改顯示名稱。

刪除和重新建立服務帳戶

刪除服務帳戶,然後建立具有相同名稱的新服務帳戶是可行的。如果您重複使用刪除的服務帳戶名稱,可能會導致非預期的行為。

服務帳戶刪除後,其角色繫節並不會立即刪除。如果您建立一個與最近刪除的服務帳戶同名的新服務帳戶,則舊的繫結可能仍然存在;但是,即使兩個帳戶具有相同的電子郵件地址,它們也不會應用於新的服務帳戶。這種行為的發生,是因為服務帳戶在建立時,便會在 Cloud IAM 中被指定一個唯一識別碼。在內部,所有都使用這些識別碼授予角色繫結,而非服務帳戶的電子郵件地址。因此,已刪除的服務帳戶存在的任何角色繫結,都不適用於使用相同電子郵件地址的新服務帳戶。

為避免混淆,我們建議使用唯一的服務帳戶名稱。如果無法做到這一點,您可以透過以下方式為新服務帳戶授予角色:

  1. 明確刪除將該角色授予舊服務帳戶的所有繫結。
  2. 將這些角色重新授予新服務帳戶。

在重新添加角色繫結之前,必須先刪除角色繫結。若僅只是再次授予角色,只會將角色授予至舊的已刪除服務帳戶而失敗,且不會發出通知。

向服務帳戶授予最低權限

您應該只為服務帳戶授予達成作業目標所需的最低權限。如要進一步瞭解,請參閱將角色授予特定資源的服務帳戶一節。

向使用者授予服務帳戶的存取權時,請記住,使用者將能夠存取服務帳戶可存取的所有資源。因此,設定服務帳戶的權限時請務必小心,嚴加管控能以服務帳戶身分進行動作的小組成員。

具有可更新 App Engine 與 Compute Engine 執行個體之 IAM 角色的使用者 (例如 App Engine 部署者Compute 執行個體管理員),能夠以執行這些執行個體的服務帳戶身分有效地執行程式碼,並間接獲得存取權,可以存取服務帳戶能存取的所有資源。同樣地,Compute Engine 執行個體的 SSH 存取權可能也會提供以執行個體執行程式碼的能力。

管理服務帳戶金鑰

服務帳戶金鑰有兩種類型:

  • GCP 代管的金鑰。這些金鑰是由 Cloud Platform 服務 (例如 App Engine 與 Compute Engine) 使用。金鑰無法下載,且會自動輪替用於簽署最多兩個星期。輪替處理是隨機的;新金鑰的使用會隨著金鑰生命週期的演進逐漸增加或減少。我們建議將服務帳戶的公開金鑰組快取儲存最多 24 小時,以確保您隨時可以存取目前的金鑰組。

  • 使用者代管的金鑰。使用者可以建立、下載及管理這些金鑰。金鑰從建立時起算,將於 10 年後過期。

對於使用者代管的金鑰,您必須確保已設置相關程序以符合金鑰管理需求,如下所示:

  • 金鑰儲存
  • 金鑰發佈
  • 金鑰撤銷
  • 金鑰輪替
  • 保護金鑰避免未經授權的使用者存取
  • 金鑰復原

有權存取金鑰的任何使用者都可透過服務帳戶存取資源。我們始終不建議開發人員將金鑰簽入來源程式碼,或是把金鑰保留在下載目錄中。

為加強金鑰的安全性,請遵循以下操作說明:

搭配使用服務帳戶與 Compute Engine

Compute Engine 執行個體必須做為服務帳戶執行,才能存取其他的 Cloud Platform 資源。請考慮以下事項,以確保 Compute Engine 執行個體的安全性:

  • 您可以在同一個專案中,用不同服務帳戶建立 VM。如要在建立 VM 後變更服務帳戶,請使用 instances.setServiceAccount 方法。

  • 您可以向服務帳戶授予 IAM 角色,藉此定義服務帳戶的存取權限。在多數情況下,您不再需要依靠範圍。這讓您得以修改 VM 服務帳戶的權限,不必重新建立執行個體。

  • 由於執行個體必須依靠服務帳戶才能存取 Cloud Platform 資源,因此請避免刪除運作中執行個體仍在使用的服務帳戶。如果您刪除這種服務帳戶,執行個體可能會發生作業錯誤。

最佳做法

  • 限制可透過服務帳戶執行動作的使用者。如果使用者具有服務帳戶的服務帳戶使用者角色,就能間接存取服務帳戶有權存取的所有資源。因此,將 serviceAccountUser 角色授予使用者時,請務必小心謹慎。

  • 只為服務帳戶授予達成作業目標所需的最低權限。如要進一步瞭解,請參閱將角色授予特定資源的服務帳戶一節。

  • 為各項服務建立的服務帳戶,只具備服務本身需要的權限。

  • 利用服務帳戶的顯示名稱來追蹤服務帳戶。建立服務帳戶時,可將服務帳戶的用途填入顯示名稱。

  • 為您的服務帳戶制訂命名慣例。

  • 執行相關程序以自動輪替由使用者代管的服務帳戶金鑰。

  • 利用 IAM service account API 執行金鑰輪替作業。

  • 透過 serviceAccount.keys.list() 方法或主控台的記錄檢視器頁面來稽核服務帳戶。

  • 請勿刪除在 Google App Engine 或 Google Compute Engine 上運作中執行個體仍在使用的服務帳戶。

本頁內容對您是否有任何幫助?請提供意見:

傳送您對下列選項的寶貴意見...

這個網頁
Cloud Identity and Access Management Documentation