Service accounts can be divided into thefollowing categories:

• User-managed service accounts, which you create and manage yourself
• Service agents, which Google Cloud creates and manages

This page describes how each type of service account is created and used.

User-managed service accounts

User-managed service accounts are service accounts that you create in yourprojects. You can update, disable, enable, and delete these service accounts atyour discretion. You can also manage other principals' access to these serviceaccounts.

You can create user-managed service accounts in your project using theIAM API, the Google Cloud console, or the Google Cloud CLI.

By default, you can create up to 100 user-managed serviceaccounts in a project. If this quota does not meet your needs, you can use theGoogle Cloud console torequest a quota adjustment. Onlyuser-created service accounts count towards this quota—default serviceaccounts andservice agents don't count towardsthe quota.

When you create a user-managed service account in your project, you choose aname for the service account. This name appears in the email address thatidentifies the service account, which uses the following format:

service-account-name@project-id.iam.gserviceaccount.com

To learn how to create a service account, seeCreate service accounts.

Default service accounts

Default service accounts are user-managed service accounts that are createdautomatically when you enable or use certain Google Cloud services. Theseservice accounts let the service deploy jobs that access otherGoogle Cloud resources. You are responsible for managing default serviceaccounts after they are created.

If your application runs in a Google Cloud environment that hasa default service account, your application can use the credentials for thedefault service account to call Google Cloud APIs. Alternatively, you cancreate your own user-managed service account and use it to authenticate. Fordetails, seeSet up Application Default Credentials.

Depending on your organization policy configuration, the default service account might automatically be granted theEditor role on your project. We strongly recommend that you disable the automatic role grant by enforcing theiam.automaticIamGrantsForDefaultServiceAccounts organization policy constraint. If you created your organization after May 3, 2024, this constraint is enforced by default.

If you disable the automatic role grant, you must decide which roles to grant to the default service accounts, and thengrant these roles yourself.

If the default service account already has the Editor role, we recommend that you replace the Editor role with less permissive roles.To safely modify the service account's roles, usePolicy Simulator to see the impact of the change, and thengrant and revoke the appropriate roles.

The following table lists the services that create default service accounts:

Service agents

Some Google Cloud services need access to your resources so that they canact on your behalf. For example, when you use Cloud Run to run acontainer, the service needs access to any Pub/Sub topics that cantrigger the container.

To meet this need, Google Cloud creates and manages service accounts formany Google Cloud services. These service accounts are known asserviceagents. You might see service agents in your project's allow policy, in auditlogs, or on the IAM page in the Google Cloud console. For afull list of service agents, seeService agents.

Service agents aren't created in your projects, so you won't see them whenviewing your projects' service accounts. You can't access them directly.

By default, service agents aren't listed in theIAM page in theGoogle Cloud console, even if they've been granted a role on your project. Toview role grants for service agents, select theInclude Google-provided rolegrants checkbox.

• Service-specific service agents
• Google APIs Service Agent
• Role manager for service agents

Service-specific service agents

Most service agents areservice-specific—they act on behalf ofindividual services. In many cases, these service agents are required forservices to function properly. For example, service agents are what allowCloud Logging sinks to write logs to Cloud Storage buckets.

Each service agent is associated with a resource. This resource is typically aproject, folder, or organization, though it can also be a service-specificresource—for example, a Cloud SQL instance. This resource defines thescope of the service agent's actions. For example, if a service agent isassociated with a project, it will act on behalf of a service for the projectand its descendant resources.

You can determine which type of resource a service agent is associated with bylooking at its email address:

• If the service agent is associated with a project, folder, or organization,its email address contains the numeric ID for that project, folder, ororganization.
• If the service agent is associated with a service-specific resource, its emailaddress contains a numeric project ID and a unique identifier. The numericproject ID indicates which project owns the resource that the service agent isassociated with. The unique identifier distinguishes the service agent fromother similar service agents in the same project.

Google APIs Service Agent

Your project's allow policy is likely to refer to a service account named theGoogle APIs Service Agent, with an email address that uses the following format:project-number@cloudservices.gserviceaccount.com.

This service account runs internal Google Cloud processes on your behalf.It is automatically granted the Editor role (roles/editor) on the project.

Role manager for service agents

Youraudit logs for IAM might refer to the serviceaccountservice-agent-manager@system.gserviceaccount.com.

This service account manages the roles that are granted to other service agents.It is visible only in audit logs.

For example, if you use a new API, Google Cloud might automatically createa new service agent and grant it roles on your project. Granting these rolesgenerates an audit log entry, which shows thatservice-agent-manager@system.gserviceaccount.com set theallow policy for the project.

Service agent creation

The exact time that a service agent is created depends on what type of resourceit's associated with.

Service agents that are associated with a service-specific resource are createdwhen you create the resource. For more information on how to identify andconfigure these service agents, review the documentation for the associatedresource.

Service agents that are associated with projects, folders, and organizations arecreated as you need them, usually when you first use a service. If necessary,you can also ask Google Cloud to create service agents for a servicebefore you use the service. For more information, seeCreate and grant roles toservice agents.

IAM roles for service agents

Some actions in Google Cloud require service agents to create and accessresources on your behalf. For example, when you create a Dataproccluster, the Dataproc service agent needs permission to createCompute Engine instances in your project in order to create the cluster.

To get this access, service agents need specific IAM roles. Manyproject-level service agents are automatically granted the roles that they need.The names of these automatically granted roles typically end inserviceAgentorServiceAgent. For other service agents, you need to grant them roles sothat the service works correctly. To find out which service agents are grantedroles automatically, see theservice agent reference.

If you need todeny certain permissions to principal sets that includeservice agents—for example, the principal setprincipalSet://goog/public:all—then we recommend adding your serviceagents as exceptions in the deny rule. This helps ensure that your servicescontinue to function properly. When adding service agents as exceptions, use theproject, folder, or organization'sservice agent principalset.

If you ask Google Cloud to create service agents before you use a service,you must grant the service agents the roles that they are typically grantedautomatically. This is because service agents that are created at a user'srequest aren't automatically granted roles. If you don't grant the serviceagents these roles, some services might not function properly. To learn how togrant these roles to service agents, seeCreate and grant roles to serviceagents.

Primary service agents

In theservice agent reference, some service agents areidentified asprimary service agents. Primary service agents are serviceagents whose email address is returned when youtrigger service agentcreation for a service.

Service agent audit logs

Sometimes, when a principal initiates an operation, a service agent executes an action on the principal's behalf. However, when you're reviewing audit logs for a service agent, it can be hard to tell who the service agent was acting on behalf of, and why.

The following service agents include these additional details in their audit logs:

• BigQuery Connection Service Agent
• BigQuery Connection Delegation Service Agent

These additional details are in theserviceDelegationHistory field of the audit log, which is nested in theauthenticationInfo field. This field contains the following information:

• The original principal who created the job
• The service agent that executed the action
• The service that the service agent belongs to
• The job ID

For example, supposeexample-user@example.com creates a job using the BigQuery Connection API. This job requires one of the BigQuery Connection API's service agents to execute an action. In this case, the audit log for the service agent's action would contain aserviceDelegationHistory field similar to the following:

{"protoPayload":{"@type":"type.googleapis.com/google.cloud.audit.AuditLog","authenticationInfo":{"principalEmail":"bqcx-442188550395-jujw@gcp-sa-bigquery-condel.iam.gserviceaccount.com","serviceDelegationHistory":{"originalPrincipal":"user:my-user@example.com","serviceMetadata":[{"principalSubject":"serviceAccount:bqcx-442188550395-jujw@gcp-sa-bigquery-condel.iam.gserviceaccount.com","serviceDomain":"bigquery.googleapis.com",}]}}}}

What's next

• Find out how tocreate and manage service accounts.
• Learn how tocreate and manage service account keys.
• Getbest practices for working with service accounts.
• Reviewbest practices for managing service account keys.