本頁面說明服務帳戶的用途，並介紹在服務帳戶生命週期的各個階段，管理服務帳戶時的重要考量。
什麼是服務帳戶？
服務帳戶是一種特殊的帳戶，使用者通常並非真人，而是應用程式或運算工作負載，例如 Compute Engine 執行個體。每個服務帳戶均使用不重複的電子郵件地址做為識別。
應用程式會透過服務帳戶，以服務帳戶本身或 Google Workspace/Cloud Identity 使用者的身分驗證，並透過網域範圍的委派，執行已授權的 API 呼叫。應用程式以服務帳戶身分進行驗證時，可存取服務帳戶有權存取的所有資源。
如要讓應用程式以服務帳戶身分驗證，最常見的做法是將服務帳戶附加至執行應用程式的資源。舉例來說，您可以將服務帳戶附加至 Compute Engine 執行個體，讓在該執行個體上執行的應用程式能以服務帳戶身分進行驗證。接著，您可以授予服務帳戶 IAM 角色，讓服務帳戶 (以及執行個體上的應用程式) 存取 Google Cloud 資源。
除了附加服務帳戶，還有其他方法可讓應用程式以服務帳戶身分驗證。舉例來說，您可以設定 Workload Identity 聯盟，允許外部工作負載以服務帳戶身分進行驗證，也可以建立服務帳戶金鑰，並在任何環境中使用該金鑰取得 OAuth 2.0 存取權杖。
如要進一步瞭解應用程式的服務帳戶驗證，請參閱工作負載身分總覽。
主體 (例如使用者和其他服務帳戶) 也可以服務帳戶的身分進行驗證。詳情請參閱本頁面的「模擬服務帳戶」一節。
服務帳戶的類型
在 Google Cloud中，服務帳戶有幾種不同類型：
使用者代管服務帳戶：您建立及管理的服務帳戶。這些服務帳戶通常做為工作負載的身分。
預設服務帳戶：啟用特定 Google Cloud 服務時，系統會自動建立使用者代管的服務帳戶。您有責任管理這些服務帳戶。
服務代理人：由Google Cloud建立及管理的服務帳戶，可讓服務代表您存取資源。
如要進一步瞭解不同類型的服務帳戶，請參閱服務帳戶類型。
服務帳戶憑證
應用程式和主體會透過下列其中一種方式，以服務帳戶身分進行驗證：
- 取得短期憑證。在許多情況下，例如附加服務帳戶和使用 gcloud CLI
--impersonate-service-account旗標的指令，系統會自動取得這些憑證，您不需要自行建立或管理。 - 使用服務帳戶金鑰簽署 JSON Web Token (JWT)，並換取存取權杖。如果服務帳戶金鑰管理不當，就會帶來安全風險，因此請盡可能選用比服務帳戶金鑰更安全的替代方案。
如要進一步瞭解服務帳戶驗證，請參閱服務帳戶憑證。
服務帳戶模擬
當經過驗證的主體 (例如使用者或其他服務帳戶) 驗證為服務帳戶，以取得服務帳戶的權限時，即為模擬服務帳戶。模擬服務帳戶可讓經過驗證的主體存取服務帳戶可存取的任何項目。只有經過驗證且具備適當權限的主體，才能模擬服務帳戶。
如果您想變更使用者的權限，但不想變更身分與存取權管理 (IAM) 政策，模擬功能就相當實用。舉例來說，您可以透過模擬功能暫時授予使用者更高的存取權，或是測試特定權限組合是否足以執行工作。您也可以使用模擬功能，在本機開發只能以服務帳戶執行的應用程式，或驗證在 Google Cloud外部執行的應用程式。
如要進一步瞭解服務帳戶模擬功能，請參閱「服務帳戶模擬」一文。
服務帳戶和 Google Workspace 網域
與使用者帳戶不同，服務帳戶並不屬於您的 Google Workspace 網域。如果您與整個 Google Workspace 網域共用 Google Workspace 資產 (例如文件或活動)，這些資產不會與服務帳戶共用。
服務帳戶無法擁有 Google Workspace 資產。但他們可以在網域的共用雲端硬碟中建立資產。在共用雲端硬碟中建立的資產由貴機構擁有及管理。
服務帳戶權限
服務帳戶是主體。也就是說，您可以授予服務帳戶 Google Cloud 資源的存取權。舉例來說，您可以授予服務帳戶專案的 Compute 管理員角色 (roles/compute.admin)。這樣一來，該服務帳戶就能管理專案中的 Compute Engine 資源。
不過，服務帳戶也是資源。也就是說，您可以授予其他主體存取服務帳戶的權限。舉例來說，您可以授予使用者服務帳戶的服務帳戶使用者角色 (roles/iam.serviceAccountUser)，讓使用者將該服務帳戶附加至資源。或者，您也可以授予使用者「服務帳戶管理員」角色 (roles/iam.serviceAccountAdmin)，讓使用者查看、編輯、停用及刪除服務帳戶。
下節將說明如何以主體和資源的身分管理服務帳戶。
以服務帳戶做為主體
由於服務帳戶是主體，因此您可以像管理任何其他主體一樣，管理服務帳戶的存取權。舉例來說，如要讓應用程式的服務帳戶存取 Cloud Storage bucket 中的物件，可以授予該服務帳戶 bucket 的 Storage 物件檢視者角色 (roles/storage.objectViewer)。或者，如要確保應用程式的服務帳戶無法變更專案的 IAM 政策，可以使用拒絕政策，禁止服務帳戶在該專案中使用 resourcemanager.projects.setIamPolicy 權限。如要進一步瞭解如何管理主體的存取權，請參閱「存取權Google Cloud」。
您可以管理個別服務帳戶的存取權，也可以管理特定專案、資料夾或機構中的所有服務帳戶。管理服務帳戶的存取權時，請使用下列主體 ID 參照服務帳戶：
| 主體類型 | 主體 ID |
|---|---|
| 個別服務帳戶 |
示例： |
| 專案中的所有服務帳戶 |
示例： |
| 資料夾中所有專案的所有服務帳戶 |
示例： |
| 機構中所有專案的所有服務帳戶 |
示例： |
與所有類型的主體一樣，您應只為服務帳戶授予達成作業目標所需的最低權限。
如果特定專案、資料夾或機構中的服務帳戶共用需求，請使用服務帳戶主體集授予角色，而非使用自訂群組。
如要瞭解如何將角色授予主體 (包括服務帳戶)，請參閱「管理專案、資料夾和機構的存取權」一文。
服務帳戶做為資源
服務帳戶也是資源，可以有自己的允許政策。因此，您可以將服務帳戶或服務帳戶的其中一個父項資源的角色授予其他主體，允許他們存取服務帳戶。舉例來說，如要讓使用者模擬服務帳戶，您可以授予該使用者服務帳戶的服務帳戶憑證建立者角色 (roles/iam.serviceAccountTokenCreator)。
授予允許使用者模擬服務帳戶的角色時，請記住，使用者將能夠存取服務帳戶可存取的所有資源。允許使用者模擬高權限服務帳戶 (例如 Compute Engine 和 App Engine 的預設服務帳戶) 時，請務必謹慎。
如要進一步瞭解可授予服務帳戶主體的角色，請參閱服務帳戶權限。
如要瞭解如何將服務帳戶的角色授予主體，請參閱管理服務帳戶的存取權。
服務帳戶生命週期
管理專案時，您可能會建立、管理及刪除許多不同的服務帳戶。本節將說明在服務帳戶生命週期的各個階段，管理服務帳戶時應注意的重點。
服務帳戶的建立位置
每個服務帳戶都位於特定專案中。建立服務帳戶後，即無法將該帳戶移至其他專案。
您可以透過幾種方式將服務帳戶歸入專案：
在同一個專案中建立服務帳戶和資源。
這種做法可讓您更輕鬆地開始使用服務帳戶。不過，如果服務帳戶分散在多個專案中，追蹤起來可能會很困難。
在不同專案中集中管理服務帳戶。
這個方法會將貴機構的所有服務帳戶放在少數幾個專案中，方便您管理服務帳戶。不過，如果您將服務帳戶附加至其他專案中的資源，則需要額外設定，才能讓這些資源使用服務帳戶做為身分。
如果服務帳戶位於某個專案，但要存取另一個專案中的資源，您通常必須在兩個專案中啟用該資源的 API。舉例來說，如果您在專案
my-service-accounts中有服務帳戶，且在專案my-application中有 Cloud SQL 執行個體，則必須在my-service-accounts和my-application中啟用 Cloud SQL API。根據預設，您最多可以在專案中建立 100 個服務帳戶。如需建立更多服務帳戶，請申請調整配額。
如要瞭解如何建立服務帳戶，請參閱「建立服務帳戶」。
禁止建立服務帳戶
如要進一步控管服務帳戶的建立位置，您可能需要禁止在機構的某些專案中建立服務帳戶。
您可以在機構、專案或資料夾中強制執行constraints/iam.disableServiceAccountCreation
組織政策限制，禁止建立服務帳戶。
強制執行這項限制前，請先考量下列限制：
如果您在專案或機構內的所有專案中強制執行這項限制，部分 Google Cloud 服務就無法建立預設服務帳戶。因此，如果專案執行的工作負載需要以服務帳戶身分驗證，專案可能沒有工作負載可用的服務帳戶。
如要解決這個問題，請啟用跨專案的服務帳戶模擬功能。啟用這項功能後，您可以在集中管理的專案中建立服務帳戶，然後將服務帳戶附加至其他專案中的資源。在這些資源上執行的工作負載可以使用附加的服務帳戶進行驗證，因此不需要預設服務帳戶。
部分功能 (例如 Workload Identity 聯盟) 需要建立服務帳戶。
如果您未使用 Workload Identity Federation，請考慮使用機構政策限制，禁止所有身分識別提供者進行聯盟。
追蹤服務帳戶
隨著時間過去，您會建立越來越多的服務帳戶，可能會導致您不記得服務帳戶的用途。
查看服務帳戶的顯示名稱是個不錯的方法，可以取得更多服務帳戶的相關資訊，像是帳戶用途或是帳戶聯絡人等。對於新服務帳戶，您可以在建立帳戶時填入顯示名稱。對於現有的服務帳戶，則可透過 serviceAccounts.update() 方法修改顯示名稱。
搭配使用服務帳戶與 Compute Engine
Compute Engine 執行個體必須以服務帳戶身分執行，才能存取其他 Google Cloud 資源。為確保 Compute Engine 執行個體安全，請考慮下列事項：
您可以在同一個專案中，使用不同的服務帳戶建立執行個體。如要在建立執行個體後變更服務帳戶，請使用
instances.setServiceAccount方法。如要為附加的服務帳戶設定授權，除了設定 IAM 角色之外，還需要設定存取權範圍。
由於執行個體必須依靠服務帳戶才能存取Google Cloud 資源，因此請避免刪除運作中執行個體仍在使用的服務帳戶。
如要進一步瞭解如何搭配使用服務帳戶與 Compute Engine，請參閱 Compute Engine 說明文件中的「服務帳戶」一文。
找出未使用的服務帳戶
一段時間後，專案中可能會出現您不再使用的服務帳戶。
未使用的服務帳戶會造成不必要的安全風險，因此建議您停用未使用的服務帳戶，然後在確定不再需要這些帳戶時刪除服務帳戶。您可以使用下列方法找出未使用的服務帳戶：
您也可以使用服務帳戶用量指標，追蹤服務帳戶和金鑰的一般用量。
如果您是 Security Command Center Premium 客戶，可以使用 Event Threat Detection，在閒置服務帳戶觸發動作時收到通知。如果服務帳戶閒置超過 180 天，就會成為休眠服務帳戶。服務帳戶一經使用，就不再處於閒置狀態。
刪除服務帳戶
刪除服務帳戶前，請先停用服務帳戶，確認是否需要該帳戶。停用的服務帳戶如果仍要使用，可重新啟用。
確認不需要服務帳戶後，即可刪除服務帳戶。
重新建立已刪除的服務帳戶
刪除服務帳戶，然後建立具有相同名稱的新服務帳戶是可行的。
服務帳戶刪除後，其角色繫節並不會立即刪除。角色繫結會列出服務帳戶，並加上 deleted: 前置字元。如需範例，請參閱「已刪除主體的政策」。
如果您建立一個與最近刪除的服務帳戶同名的新服務帳戶，則舊的繫結可能仍然存在；但是，即使兩個帳戶具有相同的電子郵件地址，它們也不會應用於新的服務帳戶。這種行為的發生，是因為服務帳戶在建立時，便會在 Identity and Access Management (IAM) 中被指定一個唯一 ID。在內部，所有都使用這些 ID 授予角色繫結，而非服務帳戶的電子郵件地址。因此，已刪除的服務帳戶存在的任何角色繫結，都不適用於使用相同電子郵件地址的新服務帳戶。
同樣地，如果您將服務帳戶附加至資源，然後刪除服務帳戶並建立同名的新服務帳戶，則新服務帳戶不會附加至資源。
為避免發生這種非預期的行為，建議您為每個服務帳戶使用新的專屬名稱。此外，如果不慎刪除服務帳戶，可以嘗試取消刪除服務帳戶，不必建立新的服務帳戶。
如果無法還原原始服務帳戶，且您需要建立同名且具有相同角色的新服務帳戶，則必須將角色授予新服務帳戶。詳情請參閱「已刪除主體的政策」。
如果新服務帳戶也需要附加至與原始服務帳戶相同的資源，請執行下列其中一項操作：
- 對於 Compute Engine 執行個體，您可以變更附加至執行個體的服務帳戶，將原始服務帳戶替換為新服務帳戶。
- 如果是其他資源，您必須刪除現有資源，然後建立相同類型的新資源，並附加新的服務帳戶。
後續步驟
- 瞭解如何建立服務帳戶。
- 瞭解使用服務帳戶的最佳做法。
- 詳閱管理服務帳戶金鑰的最佳做法。