Service Account Creation, Security and Impersonation

Authentication security for service accounts means replacing long-lived user-managed keys with short-lived, keyless credentials. Identity and Access Management (IAM) (opens in a new tab) distinguishes Google-managed short-lived credentials, which are created and rotated automatically, from user-managed keys, which the customer must store, rotate, and protect. Workload Identity Federation (opens in a new tab) is the preferred replacement for hybrid and multi-cloud workloads because no long-lived secret crosses the trust boundary.

1.1Risks of User-Managed Keys and Automatic Grants

User-managed service account keys create persistent risk because each key stays valid until it is deleted or rotated. An attacker who steals a leaked key keeps access to Google Cloud resources for as long as the key lives, which can be forever without rotation. Default service accounts add to this risk when Google Cloud automatically grants them the Editor role (roles/editor) on the project, so one compromised workload can affect the whole project.

Organization Policy Service (opens in a new tab) enforces least privilege at the organization level. The constraints/iam.automaticIamGrantsForDefaultServiceAccounts boolean constraint set to False stops automatic high-privilege grants to default service accounts. The constraints/iam.disableServiceAccountKeyCreation constraint set to True blocks creation of user-managed keys, while the separate constraints/iam.disableServiceAccountKeyUpload constraint blocks upload of externally generated public keys.

1.2Blocking New Keys With Organization Policy and Tag Exemptions

Blocking key creation with organization policy stops new unmanaged credentials from entering affected projects. Resource Manager tags (opens in a new tab) allow narrow exceptions for workloads that cannot yet migrate. The organization inherits a default enforcement value, and exempt folders or projects override that value with their own tag.

To block key creation in all non-exempt projects, complete the steps in order:

1. Obtain organization-level roles: Hold Tag Administrator (roles/resourcemanager.tagAdmin) and Organization Policy Administrator (roles/orgpolicy.policyAdmin) to create tags and enforce policy.
2. Create exemption tags: At the organization level, create tag key disableServiceAccountKeyCreation with values enforced and not_enforced.
3. Enforce by default: Attach the tag to the organization with value enforced, so all child folders and projects inherit enforcement.
4. Exempt specific resources: Attach the same tag with value not_enforced to each exempt project or folder, which overrides the inherited value for that subtree.
5. Create the tag-scoped policy: Create a policy for iam.disableServiceAccountKeyCreation that does not enforce where resource.matchTag('ORGANIZATION_ID/disableServiceAccountKeyCreation', 'not_enforced') and enforces on all other resources.

The policy flows from the organization down through folders to projects, so a key-creation request to an exempt project succeeds while the same request to a non-exempt project is denied. Tags must be attached before enforcement to avoid breaking legitimate workloads.

1.3Rotating Unavoidable Service Account Keys

Key rotation limits how long a stolen credential stays useful when keys cannot be removed. Identity and Access Management (IAM) requires rotation at least every 90 days for any remaining user-managed keys. A fixed lifetime bounds attacker access that would otherwise last indefinitely.

Enforcement uses the constraints/iam.serviceAccountKeyExpiryHours constraint with operator <= and value 2160, where 2160 hours equals 90 days. The constraint flows from the organization policy to projects in scope, and any key that would live longer violates the control. Rotation is containment only, not a substitute for keyless authentication.

1.4Authenticating Without Keys Using Workload Identity Federation

Workload Identity Federation lets workloads outside Google Cloud authenticate without a service account key. A workload identity pool, identified by iam.googleapis.com/WorkloadIdentityPool, trusts an external identity provider such as another cloud, an on-premises system, or a CI/CD platform. The external workload exchanges its native identity for short-lived Google credentials, so no long-lived secret flows from Google Cloud to the external environment.

When a client uses client libraries or the REST API, credentials flow from the external provider to Google Cloud in a fixed order:

1. Obtain external credential: The workload obtains a credential from its trusted identity provider.
2. Exchange with Security Token Service: The workload sends that credential to the Security Token Service and receives a federated token.
3. Impersonate service account: The federated token impersonates a service account and obtains a short-lived Google access token for Google Cloud APIs.

Least privilege depends on both sides of impersonation. The impersonated service account should live in the same project as the resources it accesses, and each application should use a dedicated service account. The roles/iam.workloadIdentityUser role on the service account must be granted only to specific external identities or attribute conditions, never to all pool members.

1.5Remediating Existing Workloads to Keyless Authentication

Remediation of existing workloads means working with owners to pick a keyless method and then delete keys without breaking production. Application Default Credentials (ADC) (opens in a new tab) makes migration portable because client libraries check known locations in the runtime for credentials. The same code can use user credentials during local development and short-lived service account credentials in production. ADC cannot authenticate the gcloud CLI itself and cannot be used with API keys, which work only with specific APIs.

Choose an attached service account when the workload already runs inside Google Cloud and can inherit identity from its host. Choose Workload Identity Federation for GKE when containers need pod-level isolation. Choose Workload Identity Federation when the trust boundary crosses clouds or organizations, because the external provider remains the source of identity while Google Cloud enforces authorization.

Provisioning and lifecycle management of service accounts is the practice of deciding where accounts live, controlling how they are created, and securing how they authenticate. Identity and Access Management (IAM) (opens in a new tab) provides service accounts as workload identities, while the Organization Policy Service (opens in a new tab) enforces guardrails at the organization, folder, and project levels. Policies set at a parent node are inherited by all child folders and projects unless a child has its own overriding policy.

2.1Service Account Placement in the Resource Hierarchy

Service account placement determines which project owns the service account for its entire lifetime. Each service account lives in one project and cannot be moved after creation, so the first project choice defines ownership. The number of accounts per project is limited by quota, which can be viewed in the Google Cloud console by searching for Service Account Count.

When a centralized account in one project accesses a resource in another project, the API for that resource must usually be enabled in both projects. For example, if the service account lives in my-service-accounts and the Cloud SQL instance lives in my-application, the Cloud SQL API must be enabled in both projects. Cross-project use depends on attaching the service account to the resource in the other project, which lets workloads on that resource authenticate as the attached account.

2.2Controlling Provisioning With Organization Policy

Organization policy controls where service accounts can be created and what permissions they receive by default. The constraints/iam.disableServiceAccountCreation constraint blocks service account creation when enforced on an organization, folder, or project, which supports centralization and hierarchy boundaries. Before broad enforcement, account for two limits: some Google Cloud services cannot create default service accounts in restricted projects, and features such as Workload Identity Federation (WIF) (opens in a new tab) require service account creation.

If default accounts are unavailable, enable service account impersonation across projects so workloads can use centrally created accounts. The constraints/iam.automaticIamGrantsForDefaultServiceAccounts boolean constraint set to False disables automatic high-privilege grants when services create default accounts. Without it, a default account can receive the Editor role (roles/editor) on its project, so one workload compromise could lead to control of the whole project.

2.3Secure Key Lifecycle From Blocking to Federation

The secure key lifecycle replaces long-lived user-managed credentials with short-lived authentication. The iam.disableServiceAccountKeyCreation boolean constraint set to True blocks creation of user-managed keys, and the iam.disableServiceAccountKeyUpload boolean constraint blocks upload of external public keys. When keys must remain, the constraints/iam.serviceAccountKeyExpiryHours constraint enforces rotation at least every 90 days, which is 2160 hours or less. Rotation limits how long a leaked key stays usable, while without rotation an attacker keeps access indefinitely.

Workload Identity Federation lets CI/CD systems and workloads outside Google Cloud authenticate without keys, which reduces leakage risk. Enforcement is represented by requiring iam.googleapis.com/WorkloadIdentityPool to be set. To stop new key creation while keeping narrow exceptions, apply the key-creation constraint with tags:

1. Grant admin roles: Ensure Tag Administrator (roles/resourcemanager.tagAdmin) and Organization Policy Administrator (roles/orgpolicy.policyAdmin) at the organization level.
2. Create exemption tag: At the organization level, create tag key disableServiceAccountKeyCreation with values enforced and not_enforced.
3. Set organization default: Attach the tag to the organization with value enforced, so children inherit enforcement.
4. Exempt specific resources: Attach the tag with value not_enforced to each exempt project or folder, which overrides the inherited value.
5. Create tagged policy: Create a policy where iam.disableServiceAccountKeyCreation is not enforced when resource.matchTag('ORGANIZATION_ID/disableServiceAccountKeyCreation', 'not_enforced') and is enforced on all other resources.

For existing workloads, choose the replacement by environment. First determine whether code runs in single-user development such as a workstation or Cloud Shell versus production, then determine whether it runs inside or outside Google Cloud. Code in containers on Google Kubernetes Engine (GKE) uses Workload Identity Federation for GKE to attach accounts to pods, while other code in Google Cloud attaches a service account directly to the resource.

2.4Tracking, Impersonation, and Ongoing Management

Ongoing management keeps the service account inventory understandable and limits who can act as each account. The display name of a service account captures purpose, owner, or contact information at creation time, which prevents confusion as account numbers grow. Consistent display names and exemption tag naming support governance across folders and projects.

Access to use a service account is granted by binding a role to a principal on the service account or on a parent resource. For example, granting Service Account Token Creator (roles/iam.serviceAccountTokenCreator) on the service account lets the principal impersonate that account. Impersonation transfers all of the service account's resource access to the impersonating user, so use caution with highly privileged Compute Engine and App Engine default service accounts.

Authorization, impersonation, and least-privilege enforcement follow from the dual nature of a service account (opens in a new tab). A service account is both a principal that can receive Identity and Access Management (IAM) roles on resources such as Cloud Storage buckets, and a resource that other principals such as users or groups can be given permission to use. Least privilege must apply on both sides: limit what the service account can access and limit who can use the service account.

3.1Authorization for Service Accounts as Principals

Authorization for service accounts as principals controls what Google Cloud resources the service account itself can reach. A service account gains access when bound to a role on a resource, for example Storage Object Viewer (roles/storage.objectViewer) on a bucket or Compute Admin (roles/compute.admin) on a project, and it can also be limited by a deny policy such as denying resourcemanager.projects.setIamPolicy. Traffic flows from the workload authenticated as the service account to the target API, and IAM checks both allow and deny policies before permitting the call.

Least-privilege authorization requires precise, narrow grants:

• Grant only predefined or custom roles that match the workload, and do not grant the basic Owner, Editor, or Viewer roles in production.
• Create dedicated, single-purpose service accounts for each application instead of sharing Compute Engine or App Engine default accounts.
• Disable automatic Editor grants by enforcing the iam.automaticIamGrantsForDefaultServiceAccounts organization policy constraint, enforced by default for organizations created after May 3, 2024.
• Do not rely on Compute Engine access scopes as a replacement for IAM, because scopes are coarse-grained and cannot restrict access to specific buckets or resources.
• Use role recommendations to remove unused permissions and lateral movement insights to find where a service account could move to other resources.

Single-purpose accounts preserve attribution, because Cloud Audit Logs record the service account email that acted but do not record which application behind a shared account acted.

3.2Control of Service Accounts as Resources

Control of service accounts as resources determines which principals can attach, administer, or impersonate a specific account. A service account belongs to a project in the resource hierarchy, so access can be granted on the individual account, the enclosing project, a parent folder, or the organization. The policy that protects the service account applies to whoever tries to use it, while the roles granted to the service account control what that user can then reach.

Manage access on each individual service account rather than at the project or folder level. If a user receives the Service Account Token Creator role on a project, that user can impersonate every service account in the project and can potentially reach all resources those accounts can access, including resources outside that project. Individual bindings keep the blast radius to one workload identity and avoid over-granting through hierarchy inheritance.

Privilege-escalation boundaries around attached accounts enforce the same principle. Any code on a Compute Engine virtual machine (VM) instance with an attached service account can by default reach the metadata server to request tokens for that account, so untrusted startup scripts, guest policies, CI/CD code, or user-submitted code must be as well protected as the account itself. Shell access must be equally restricted, with OS Login on Linux requiring both OS Login permission and the iam.serviceAccounts.actAs permission on the attached account, and with host firewalls or Identity-Aware Proxy TCP forwarding limiting who can reach the VM and metadata server.

3.3Impersonation and the Two Control Roles

Service account impersonation occurs when an already authenticated principal authenticates as a service account to gain its permissions. The impersonating principal's requests flow to Google Cloud APIs under the service account identity, so the principal can access whatever the service account can access without changing resource IAM policies. Impersonation is used for temporary elevated access, permission testing, local development as a service account, and authenticating workloads outside Google Cloud.

Choose Service Account User when the principal needs to deploy a workload that runs as the service account. Choose Service Account Token Creator when the principal needs to act as the account on demand from the Google Cloud CLI, client libraries, or the Service Account Credentials API. A local Application Default Credentials (ADC) file created with gcloud auth application-default login --impersonate-service-account is supported only for the Go, Java, Node.js, and Python client libraries.

3.4Temporary Elevation and Downscoping Without Long-Lived Keys

Temporary elevation with the Service Account Credentials API lets an application use high privilege only when needed instead of running continuously with broad access. A supervisor service account holds Service Account Token Creator on narrowly scoped workload accounts, and a dedicated token-broker component uses the supervisor to mint short-lived tokens for each job. Long-lived keys are avoided because anyone holding the private key can authenticate as the service account from anywhere.

Credentials move from the broker to each workload part in order:

1. Create dedicated service accounts: Create one service account for each application part or job type and grant each account access only to the resources that part needs.
2. Create a supervisor account: Create a separate supervisor service account and grant it Service Account Token Creator on the dedicated workload accounts.
3. Isolate the broker: Allow only the token-broker component to use the supervisor service account.
4. Issue short-lived tokens: The broker calls the Service Account Credentials API to obtain short-lived access tokens for the appropriate workload account and passes each token only to the part that needs it.

Credential Access Boundaries further downscope those short-lived tokens to a subset of permissions, and domain-wide delegation is avoided because it would let a service account impersonate any user in a Cloud Identity or Google Workspace account, including super-admins. When delegation or external access cannot use Workload Identity Federation, prefer impersonation with user credentials over creating a service account key.

3.5Monitoring Impersonation and Anomalous Access With Audit Logs

Monitoring with Cloud Audit Logs provides the record that links service account activity to potential abuse, including privilege escalation, spoofing, and non-repudiation threats. When logs show that a service account changed a resource or accessed data, that entry alone may not identify which human or workload impersonated the account, so correlation depends on IAM data-access logs and application context. Enable data access logs for IAM APIs so token creation, getIamPolicy, and setIamPolicy calls on service accounts are visible alongside the resource changes they enabled.

Effective detection depends on least-privilege design. Shared accounts, project-level Token Creator grants, and generic default accounts make it impossible to trace an event to one application, while single-purpose accounts, per-account bindings, CI/CD history correlated with audit timestamps, and custom application log entries for individual end users restore the chain from impersonating principal to service account to target resource. Unused service accounts are disabled before they are deleted so lateral movement paths shrink without immediately breaking unknown dependencies, and role recommendations and policy audits keep remaining grants aligned to actual use.

Key Facts

• A service account lives in one project, cannot be moved after creation, and cross-project use requires attaching the account to the resource in the other project with required APIs enabled in both projects.
• User-managed service account keys remain valid until deleted or rotated, must be rotated at least every 90 days (2160 hours), and new keys and external key uploads are blocked by two separate organization policy constraints.
• Workload Identity Federation exchanges an external identity for short-lived Google credentials through a workload identity pool and the Security Token Service, so no long-lived secret crosses the trust boundary.
• Service Account User (iam.serviceAccounts.actAs) allows attaching an account to a resource, while Service Account Token Creator (iam.serviceAccounts.getAccessToken) allows requesting short-lived tokens directly, and both must be granted on the individual service account for least privilege.