{
	"id": "714102de-0a3f-4857-8f71-e2f8fcd46929",
	"created_at": "2026-04-06T00:14:55.614173Z",
	"updated_at": "2026-04-10T03:20:23.240122Z",
	"deleted_at": null,
	"sha1_hash": "b8ea1c75dcbf4da8f859497af51d9c87b4306354",
	"title": "Roles for service account authentication",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 87340,
	"plain_text": "Roles for service account authentication\r\nArchived: 2026-04-05 16:43:17 UTC\r\nPrincipals can use service accounts to authenticate in a few different ways. Each type of authentication requires\r\nthe principal to have specific Identity and Access Management (IAM) permissions on the service account.\r\nThis page describes the roles that you can grant to principals to let them impersonate service accounts or attach\r\nservice accounts to resources. It also describes the permissions that you need in common scenarios.\r\nTo learn about different ways to authenticate with a service account, see Service account credentials and Service\r\naccount impersonation.\r\nThis section describes the roles that let principals authenticate with service accounts. To learn how to grant and\r\nrevoke these roles, see Manage access to service accounts.\r\nService Account User role\r\nThe Service Account User role ( roles/iam.serviceAccountUser ) lets a principal attach a service account to a\r\nresource. When the code running on that resource needs to authenticate, it can get credentials for the attached\r\nservice account.\r\nThis role does not allow principals to create short-lived credentials for service accounts, or to use the --\r\nimpersonate-service-account flag for the Google Cloud CLI. To complete these tasks, you need the Service\r\nAccount Token Creator role on the service account.\r\nService Account Token Creator role\r\nThe Service Account Token Creator role ( roles/iam.serviceAccountTokenCreator ) lets principals create short-lived credentials for a service account.\r\nThe Service Account Token Creator role lets you create the following types of short-lived credentials:\r\nOAuth 2.0 access tokens, which you can use to authenticate with Google APIs\r\nOpenID Connect (OIDC) ID tokens\r\nSigned JSON Web Tokens (JWTs) and binary blobs\r\nThe Service Account Token Creator role also lets principals use the --impersonate-service-account flag for the\r\ngcloud CLI. When you use this flag, the gcloud CLI automatically creates short-lived credentials for the service\r\naccount.\r\nThe role's permissions include the following:\r\niam.serviceAccounts.getAccessToken : lets you create OAuth 2.0 access tokens\r\niam.serviceAccounts.getOpenIdToken : lets you create OpenID Connect (OIDC) ID tokens\r\nhttps://cloud.google.com/iam/docs/service-account-permissions\r\nPage 1 of 5\n\niam.serviceAccounts.implicitDelegation : lets service accounts get tokens in a delegation chain\r\niam.serviceAccounts.signBlob : lets you sign binary blobs\r\niam.serviceAccounts.signJwt : lets you sign JWTs\r\nService Account OpenID Connect Identity Token Creator\r\nThe Service Account OpenID Connect Identity Token Creator role\r\n( roles/iam.serviceAccountOpenIdTokenCreator ) lets principals create short-lived OIDC ID tokens. If you only\r\nneed to create OIDC ID tokens, use this role. If you need to create other types of tokens, use the Service Account\r\nToken Creator role instead.\r\nThe role includes the iam.serviceAccounts.getOpenIdToken permission, which lets you create an OIDC ID\r\ntoken.\r\nWorkload Identity User role\r\nThe Workload Identity User role ( roles/iam.workloadIdentityUser ) lets principals impersonate service\r\naccounts from GKE workloads.\r\nThe role's permissions include the following:\r\niam.serviceAccounts.getAccessToken : lets you create OAuth 2.0 access tokens\r\niam.serviceAccounts.getOpenIdToken : lets you create OpenID Connect (OIDC) ID tokens\r\nService account permissions for common scenarios\r\nService accounts can be used in many different scenarios, and each of them requires certain permissions. This\r\nsection describes common scenarios and what permissions are required.\r\nAttaching service accounts to resources\r\nIf you want to start a long-running job that authenticates as a service account, you need to attach a service account\r\nto the resource that will run the job.\r\nPermissions:\r\nPermissions to create the resource\r\niam.serviceAccounts.actAs\r\nTo find roles that include these permissions, search the roles list for the permissions.\r\nThere are several different Google Cloud resources that can run long-running jobs as service accounts. Some\r\nexamples of these resources include:\r\nCompute Engine VMs\r\nApp Engine apps\r\nCloud Run functions\r\nhttps://cloud.google.com/iam/docs/service-account-permissions\r\nPage 2 of 5\n\nWhen you create these resources, you have the option to attach a service account. This service account acts as the\r\nresource's identity.\r\nTo create a resource and attach a service account, you need permissions to create that resource and permission to\r\nattach the service account to resources. Permission to attach service accounts to resources is provided by any role\r\nthat includes the iam.serviceAccounts.actAs permission—for example, the Service Account User role\r\n(roles/iam.serviceAccountUser).\r\nAfter you create the resource and attach a service account to it, you can start a long-running job on the resource.\r\nThe job runs as the service account that is attached to the resource, and uses that service account to authorize\r\nrequests to Google Cloud APIs.\r\nTo learn more about attaching service accounts to resources, see Attaching a service account to a resource.\r\nImpersonating a service account\r\nPermissions:\r\niam.serviceAccounts.getAccessToken\r\niam.serviceAccounts.signBlob\r\niam.serviceAccounts.signJwt\r\niam.serviceAccounts.implicitDelegation\r\nRoles:\r\nroles/iam.serviceAccountTokenCreator (Service Account Token Creator)\r\nOnce granted the required permissions, a user (or another service account) can impersonate the service account in\r\na few common scenarios.\r\nFirst, the user can authenticate as the service account. For example, they can get short-lived credentials for the\r\nservice account using the iam.serviceAccounts.getAccessToken permission and by calling the\r\ngenerateAccessToken() method. Or, they can use the --impersonate-service-account flag for gcloud CLI to\r\nimpersonate the service account. When a user authenticates as a service account, they can issue commands to\r\nGoogle Cloud and can access all resources to which the service account has access.\r\nSecond, the user can get artifacts signed by the Google-managed private key of the service account using the\r\niam.serviceAccounts.signBlob permission and by calling either the signBlob() or signJwt() method. The\r\nGoogle-managed private key is always held in escrow and is never directly exposed. signBlob() allows signing\r\nof arbitrary payloads (such as Cloud Storage-signed URLs), while signJwt() only allows signing well-formed\r\nJWTs.\r\nFinally, the user can impersonate the service account without ever retrieving a credential for the service account.\r\nThis is an advanced use case, and is only supported for programmatic access using the generateAccessToken()\r\nmethod. In scenarios with at least 3 service accounts, namely A, B, and C: service account A can get an access\r\ntoken for service account C if service account A is granted the iam.serviceAccounts.implicitDelegation\r\npermission on B, and B is granted the iam.serviceAccounts.getAccessToken permission on C.\r\nhttps://cloud.google.com/iam/docs/service-account-permissions\r\nPage 3 of 5\n\nGenerating OpenID Connect (OIDC) ID tokens\r\nPermissions:\r\niam.serviceAccounts.getOpenIdToken\r\nRoles:\r\nroles/iam.serviceAccountOpenIdTokenCreator (Service Account OpenID Connect Identity Token\r\nCreator)\r\nA user (or service) can generate an OpenID Connect (OIDC)-compatible JWT token signed by the Google OIDC\r\nProvider (accounts.google.com) that represents the identity of the service account using the\r\niam.serviceAccounts.getOpenIdToken permission.\r\nThese tokens are not directly accepted by most Google APIs without your organization deploying additional\r\nidentity federation to grant access to Google.\r\nGenerating external private keys\r\nPermissions:\r\niam.serviceAccountKeys.create\r\nRoles:\r\nroles/editor (Editor)\r\nroles/iam.serviceAccountKeyAdmin (Service Account Key Admin)\r\nA user or service can generate external private key material (RSA) that can be used to authenticate directly to\r\nGoogle as the service account. This key material can then be used with Application Default Credentials (ADC)\r\nlibraries, or with the gcloud auth activate-service-account command. Any person who gains access to the\r\nkey material will then have full access to all resources to which the service account has access. Such private key\r\nmaterial should be treated with the highest concern, and should be considered less secure the longer the material\r\nexists. Therefore, rotating private key material is critical to maintaining strong security.\r\nService account permissions that enable other capabilities\r\nSome permissions for service account credentials enable multiple capabilities. For example,\r\niam.serviceAccounts.signBlob and iam.serviceAccounts.signJwt also let principals generate access tokens\r\nand ID tokens for a service account. Additionally, because iam.serviceAccounts.signBlob allows principals to\r\nsign any kind of data, it also lets principals sign JWTs.\r\nBefore adding any of these permissions to custom roles, ensure that you understand what actions each permission\r\nenables.\r\nThe following table shows the operations enabled by these permissions:\r\nhttps://cloud.google.com/iam/docs/service-account-permissions\r\nPage 4 of 5\n\nPermission Enabled operations\r\niam.serviceAccounts.getAccessToken Get an access token for the service account\r\niam.serviceAccounts.getOpenIdToken Get an ID token for the service account\r\niam.serviceAccounts.signJwt\r\nSign a JWT\r\nGet an access token or ID token for the service account by\r\nusing a JWT bearer token.\r\niam.serviceAccounts.signBlob\r\nSign any type of blob, including JWTs\r\nGet an access token or ID token for the service account by\r\nusing a JWT bearer token.\r\nBest practices for granting roles on service accounts\r\nIn scenarios where a service account has been granted permissions to perform highly-privileged operations, be\r\ncautious when granting the Service Account User role or its included permissions to a user on that service account.\r\nService accounts represent your service-level security. The security of the service is determined by the people who\r\nhave IAM roles to manage and use the service accounts, and people who hold service account keys for those\r\nservice accounts. Best practices to ensure security include the following:\r\nUse the IAM API to audit the service accounts, the keys, and the allow policies on those service accounts.\r\nIf your service accounts don't need service account keys, disable or delete them.\r\nIf users don't need permission to manage or use service accounts, then remove them from the applicable\r\nallow policy.\r\nUnderstand how granting certain permissions for service accounts can effectively enable other capabilities.\r\nMake sure that service accounts have the fewest permissions possible. Use default service accounts with\r\ncaution, because they are automatically granted the Editor ( roles/editor ) role on the project.\r\nTo learn more about best practices, see Best practices for working with service accounts.\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-permissions\r\nhttps://cloud.google.com/iam/docs/service-account-permissions\r\nPage 5 of 5",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"MITRE"
	],
	"references": [
		"https://cloud.google.com/iam/docs/service-account-permissions"
	],
	"report_names": [
		"service-account-permissions"
	],
	"threat_actors": [],
	"ts_created_at": 1775434495,
	"ts_updated_at": 1775791223,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/b8ea1c75dcbf4da8f859497af51d9c87b4306354.pdf",
		"text": "https://archive.orkl.eu/b8ea1c75dcbf4da8f859497af51d9c87b4306354.txt",
		"img": "https://archive.orkl.eu/b8ea1c75dcbf4da8f859497af51d9c87b4306354.jpg"
	}
}