{
	"id": "d3cde49f-bb54-40a9-a919-65303ef22067",
	"created_at": "2026-04-06T00:19:35.355852Z",
	"updated_at": "2026-04-10T03:19:58.918648Z",
	"deleted_at": null,
	"sha1_hash": "bbce18e6669ffec1ed1667b781e2475799e881ae",
	"title": "Service accounts overview",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 99436,
	"plain_text": "Service accounts overview\r\nArchived: 2026-04-05 23:38:57 UTC\r\nThis page explains what service accounts are and describes important considerations for managing your service\r\naccounts at each stage of their lifecycle.\r\nWhat are service accounts?\r\nA service account is a special kind of account typically used by an application or compute workload, such as a\r\nCompute Engine instance, rather than a person. A service account is identified by its email address, which is\r\nunique to the account.\r\nApplications use service accounts to make authorized API calls by authenticating as either the service account\r\nitself, or as Google Workspace or Cloud Identity users through domain-wide delegation. When an application\r\nauthenticates as a service account, it has access to all resources that the service account has permission to access.\r\nThe most common way to let an application authenticate as a service account is to attach a service account to the\r\nresource running the application. For example, you can attach a service account to a Compute Engine instance so\r\nthat applications running on that instance can authenticate as the service account. Then, you can grant the service\r\naccount IAM roles to let the service account—and, by extension, applications on the instance—access Google\r\nCloud resources.\r\nThere are other ways to let applications authenticate as service accounts besides attaching a service account. For\r\nexample, you could set up Workload Identity Federation to allow external workloads to authenticate as service\r\nhttps://cloud.google.com/iam/docs/service-account-overview\r\nPage 1 of 8\n\naccounts, or create a service account key and use it in any environment to obtain OAuth 2.0 access tokens.\r\nTo learn more about service account authentication for applications, see Overview of identities for workloads.\r\nPrincipals, such as users and other service accounts, can also authenticate as service accounts. For more\r\ninformation, see Service account impersonation on this page.\r\nTypes of service accounts\r\nIn Google Cloud, there are several different types of service accounts:\r\nUser-managed service accounts: Service accounts that you create and manage. These service accounts are\r\noften used as identities for workloads.\r\nDefault service accounts: User-managed service accounts that are created automatically when you enable\r\ncertain Google Cloud services. You are responsible for managing these service accounts.\r\nService agents: Service accounts that are created and managed by Google Cloud, and that allow services to\r\naccess resources on your behalf.\r\nTo learn more about the different types of service accounts, see Types of service accounts.\r\nService account credentials\r\nApplications and principals authenticate as a service account by doing one of the following:\r\nObtaining short-lived credentials. In many cases, such as attached service accounts and commands using\r\nthe gcloud CLI --impersonate-service-account flag, these credentials are obtained automatically—you\r\ndon't need to create or manage them yourself.\r\nUsing a service account key to sign a JSON Web Token (JWT) and exchanging it for an access token.\r\nBecause service account keys are a security risk if not managed correctly, you should choose a more secure\r\nalternative to service account keys whenever possible.\r\nTo learn more about service account authentication, see Service account credentials.\r\nService account impersonation\r\nWhen an authenticated principal, such as a user or another service account, authenticates as a service account to\r\ngain the service account's permissions, it's called impersonating the service account. Impersonating a service\r\naccount lets an authenticated principal access whatever the service account can access. Only authenticated\r\nprincipals with the appropriate permissions can impersonate service accounts.\r\nImpersonation is useful when you want to change a user's permissions without changing your Identity and Access\r\nManagement (IAM) policies. For example, you can use impersonation to temporarily grant a user elevated access,\r\nor to test whether a specific set of permissions is sufficient for a task. You can also use impersonation to locally\r\ndevelop applications that can only run as a service account, or to authenticate applications that run outside of\r\nGoogle Cloud.\r\nhttps://cloud.google.com/iam/docs/service-account-overview\r\nPage 2 of 8\n\nTo learn more about service account impersonation, see Service account impersonation.\r\nService accounts and Google Workspace domains\r\nService accounts do not belong to your Google Workspace domain, unlike user accounts. If you share Google\r\nWorkspace assets, like documents or events, with your entire Google Workspace domain, they are not shared with\r\nservice accounts.\r\nService accounts can't own Google Workspace assets. They can, however, create assets in a shared drive in the\r\ndomain. Assets created in a shared drive are owned and managed by your organization.\r\nService account permissions\r\nService accounts are principals. This means that you can grant service accounts access to Google Cloud resources.\r\nFor example, you could grant a service account the Compute Admin role ( roles/compute.admin ) on a project.\r\nThen, the service account would be able to manage Compute Engine resources in that project.\r\nHowever, service accounts are also resources. This means that you can give other principals permission to access\r\nthe service account. For example, you could grant a user the Service Account User role\r\n( roles/iam.serviceAccountUser ) on a service account to let the user attach that service account to resources. Or,\r\nyou could grant a user the Service Account Admin role ( roles/iam.serviceAccountAdmin ) to let the user do\r\nthings like view, edit, disable, and delete the service account.\r\nThe following sections discuss how to manage service accounts as principals and as resources.\r\nService accounts as principals\r\nBecause service accounts are principals, you can manage access for service accounts just like you would for any\r\nother principal. For example, if you want to let your application's service account access objects in a Cloud\r\nStorage bucket, you can grant the service account the Storage Object Viewer role ( roles/storage.objectViewer )\r\non the bucket. Or, if you want to ensure that an application's service account can't change a project's IAM policies,\r\nyou could use a deny policy to prevent the service account from using the\r\nresourcemanager.projects.setIamPolicy permission on that project. To learn more about managing access for\r\nprincipals, see Access in Google Cloud.\r\nYou can manage access for individual service accounts or for all service accounts in a specific project, folder, or\r\norganization. When managing access for service accounts, use the following principal identifiers to refer to the\r\nservice accounts:\r\nPrincipal type Principal identifier\r\nhttps://cloud.google.com/iam/docs/service-account-overview\r\nPage 3 of 8\n\nAn individual service\r\naccount\r\nserviceAccount:SA_EMAIL_ADDRESS\r\nExample: serviceAccount:my-service-account@my-project.iam.gserviceaccount.com\r\nAll service accounts in a\r\nproject\r\nprincipalSet://cloudresourcemanager.googleapis.com/projects/\r\nPROJECT_NUMBER/type/ServiceAccount\r\nExample: principalSet://cloudresourcemanager.googleapis.com/projects/\r\n123456789012/type/ServiceAccount\r\nAll service accounts in all\r\nprojects in a folder\r\nprincipalSet://cloudresourcemanager.googleapis.com/folders/\r\nFOLDER_NUMBER/type/ServiceAccount\r\nExample: principalSet://cloudresourcemanager.googleapis.com/folders/\r\n123456789012/type/ServiceAccount\r\nAll service accounts in all\r\nprojects in an organization\r\nprincipalSet://cloudresourcemanager.googleapis.com/organizations/\r\nORGANIZATION_NUMBER/type/ServiceAccount\r\nExample: principalSet://cloudresourcemanager.googleapis.com/\r\norganizations/123456789012/type/ServiceAccount\r\nIf service accounts in a specific project, folder, or organization share requirements, then use service account\r\nprincipal sets to grant them roles instead of using custom groups.\r\nAs with all types of principals, you should only give the service account the minimum set of permissions required\r\nto achieve its goal.\r\nTo learn how to grant roles to principals, including service accounts, see Manage access to projects, folders, and\r\norganizations.\r\nService accounts as resources\r\nService accounts are also resources that can have their own allow policies. As a result, you can let other principals\r\naccess a service account by granting them a role on the service account, or on one of the service account's parent\r\nresources. For example, to let a user impersonate a service account, you could grant the user the Service Account\r\nToken Creator role ( roles/iam.serviceAccountTokenCreator ) on the service account.\r\nWhen granting a role that allows a user to impersonate a service account, keep in mind that the user can access all\r\nthe resources that the service account can access. Use caution when letting users impersonate highly privileged\r\nhttps://cloud.google.com/iam/docs/service-account-overview\r\nPage 4 of 8\n\nservice accounts, such as the Compute Engine and App Engine default service accounts.\r\nFor more information on the roles that you can grant to principals on service accounts, see Service account\r\npermissions.\r\nTo learn how to grant a principal a role on a service account, see Manage access to service accounts.\r\nService account lifecycle\r\nAs you manage your projects, you'll likely create, manage, and delete many different service accounts. This\r\nsection describes key considerations for managing your service accounts at the various stages of their lifecycle.\r\nWhere to create service accounts\r\nEach service account is located in a project. After you create a service account, you cannot move it to a different\r\nproject.\r\nThere are a few ways to organize your service accounts into projects:\r\nCreate service accounts and resources in the same project.\r\nThis approach makes it easier to get started with service accounts. However, it can be difficult to keep track\r\nof your service accounts when they are spread across many projects.\r\nCentralize service accounts in separate projects.\r\nThis approach puts all of the service accounts for your organization in a small number of projects, which\r\ncan make the service accounts easier to manage. However, it requires extra setup if you attach service\r\naccounts to resources in other projects, which allows those resources to use the service account as their\r\nidentity.\r\nWhen a service account is in one project, and it accesses a resource in another project, you usually must\r\nenable the API for that resource in both projects. For example, if you have a service account in the project\r\nmy-service-accounts and a Cloud SQL instance in the project my-application , you must enable the\r\nCloud SQL API in both my-service-accounts and my-application .\r\nThe number of service accounts that you can have in each project depends on your project. To view the quota for a\r\nproject, view your project's quotas in the Google Cloud console and search for Service Account Count.\r\nTo learn how to create a service account, see Create service accounts.\r\nPrevent the creation of service accounts\r\nTo better control where service accounts are created, you might want to prevent service account creation in some\r\nprojects in your organization.\r\nYou can prevent the creation of service accounts by enforcing the\r\nconstraints/iam.disableServiceAccountCreation organization policy constraint in an organization, project, or\r\nhttps://cloud.google.com/iam/docs/service-account-overview\r\nPage 5 of 8\n\nfolder.\r\nBefore you enforce this constraint, consider the following limitations:\r\nIf you enforce this constraint in a project, or in all projects within an organization, then some Google Cloud\r\nservices cannot create default service accounts. As a result, if the project runs workloads that need to\r\nauthenticate as a service account, the project might not contain a service account that the workload can use.\r\nTo address this issue, you can enable service account impersonation across projects. When you enable this\r\nfeature, you can create service accounts in a centralized project, then attach the service accounts to\r\nresources in other projects. Workloads running on those resources can use the attached service accounts to\r\nauthenticate, making the default service accounts unnecessary.\r\nSome features, such as Workload Identity Federation, require you to create service accounts.\r\nIf you don't use Workload Identity Federation, consider using organization policy constraints to block\r\nfederation from all identity providers.\r\nKeep track of service accounts\r\nOver time, as you create more and more service accounts, you might lose track of which service account is used\r\nfor what purpose.\r\nThe display name of a service account is a good way to capture additional information about the service account,\r\nsuch as the purpose of the service account or a contact person for the account. For new service accounts, you can\r\npopulate the display name when creating the service account. For existing service accounts use the\r\nserviceAccounts.update() method to modify the display name.\r\nUse service accounts with Compute Engine\r\nCompute Engine instances need to run as service accounts to have access to other Google Cloud resources. To\r\nhelp secure your Compute Engine instances, consider the following:\r\nYou can create instances in the same project with different service accounts. To change the service account\r\nof an instance after it's created, use the instances.setServiceAccount method.\r\nTo set up authorization for attached service accounts, you need to configure access scopes in addition to\r\nconfiguring IAM roles.\r\nSince instances depend on their service accounts to have access to Google Cloud resources, avoid deleting\r\nservice accounts when they are still used by running instances.\r\nTo learn more about using service accounts with Compute Engine, see Service accounts in the Compute Engine\r\ndocumentation.\r\nIdentify unused service accounts\r\nAfter some time, you might have service accounts in your projects that you no longer use.\r\nhttps://cloud.google.com/iam/docs/service-account-overview\r\nPage 6 of 8\n\nUnused service accounts create an unnecessary security risk, so we recommend disabling unused service accounts,\r\nthen deleting the service accounts when you are sure that you no longer need them. You can use the following\r\nmethods to identify unused service accounts:\r\nService account insights tell you which service accounts in your project have not authenticated in the past\r\n90 days.\r\nActivity Analyzer lets you check when a service account or key was last used.\r\nYou can also use service account usage metrics to track service account and key usage generally.\r\nIf you are an Security Command Center Premium customer, you can use Event Threat Detection to get a\r\nnotification when a dormant service account triggers an action. Dormant service accounts are service accounts that\r\nhave been inactive for more than 180 days. After a service account is used, it is no longer dormant.\r\nDelete service accounts\r\nBefore deleting a service account, disable the service account to make sure it isn't necessary. Disabled service\r\naccounts can be re-enabled if they are still in use.\r\nAfter you confirm that a service account isn't necessary, you can delete the service account.\r\nRecreate deleted service accounts\r\nIt is possible to delete a service account and then create a new service account with the same name.\r\nWhen you delete a service account, its role bindings are not immediately deleted. Instead, the role bindings list the\r\nservice account with the prefix deleted: . For an example, see Policies with deleted principals.\r\nIf you create a new service account with the same name as a recently deleted service account, the old bindings\r\nmay still exist; however, they will not apply to the new service account even though both accounts have the\r\nsame email address. This behavior occurs because service accounts are given a unique ID within Identity and\r\nAccess Management (IAM) at creation. Internally, all role bindings are granted using these IDs, not the service\r\naccount's email address. Therefore, any role bindings that existed for a deleted service account do not apply to a\r\nnew service account that uses the same email address.\r\nSimilarly, if you attach a service account to a resource, then delete the service account and create a new service\r\naccount with the same name, the new service account will not be attached to the resource.\r\nTo prevent this unexpected behavior, consider using a new, unique name for every service account. Also, if you\r\naccidentally delete a service account, you can try to undelete the service account instead of creating a new service\r\naccount.\r\nIf you cannot undelete the original service account, and you need to create a new service account with the same\r\nname and the same roles, you must grant the roles to the new service account. For details, see Policies with\r\ndeleted principals.\r\nhttps://cloud.google.com/iam/docs/service-account-overview\r\nPage 7 of 8\n\nIf you also need the new service account to be attached to the same resources as the original service account, do\r\none of the following:\r\nFor Compute Engine instances, you can change the service account that is attached to the instance to\r\nreplace the original service account with the new service account.\r\nFor all other resources, you must delete the existing resource, then create a new resource of the same type\r\nand attach the new service account.\r\nWhat's next\r\nFind out how to create service accounts.\r\nGet best practices for working with service accounts.\r\nReview best practices for managing service account keys.\r\nTry it for yourself\r\nIf you're new to Google Cloud, create an account to evaluate how our products perform in real-world scenarios.\r\nNew customers also get $300 in free credits to run, test, and deploy workloads.\r\nGet started for free\r\nSource: https://cloud.google.com/iam/docs/service-account-overview\r\nhttps://cloud.google.com/iam/docs/service-account-overview\r\nPage 8 of 8",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"MITRE"
	],
	"references": [
		"https://cloud.google.com/iam/docs/service-account-overview"
	],
	"report_names": [
		"service-account-overview"
	],
	"threat_actors": [],
	"ts_created_at": 1775434775,
	"ts_updated_at": 1775791198,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/bbce18e6669ffec1ed1667b781e2475799e881ae.pdf",
		"text": "https://archive.orkl.eu/bbce18e6669ffec1ed1667b781e2475799e881ae.txt",
		"img": "https://archive.orkl.eu/bbce18e6669ffec1ed1667b781e2475799e881ae.jpg"
	}
}