Example logs for service accounts

This page shows examples of the audit logs that are generated when you manageor use a service account.

Note: Each example shows only the most relevant fields in the log entries.

For more information about enabling and viewing audit logs, seeIAM audit logging.

Logs for creating service accounts

When you create or modify a service account, Identity and Access Management (IAM)generates log entries. The following example shows a log entry for creating aservice account:

{"protoPayload":{"@type":"type.googleapis.com/google.cloud.audit.AuditLog","authenticationInfo":{"principalEmail":"example-user@example.com"},"methodName":"google.iam.admin.v1.CreateServiceAccount","response":{"email":"my-service-account@my-project.iam.gserviceaccount.com","@type":"type.googleapis.com/google.iam.admin.v1.ServiceAccount","display_name":"My service account."}},"resource":{"type":"service_account"}}

Logs for granting roles

This section shows the log entries you receive when you grant roles that arerelated to service accounts.

Note: You might see log entries in which the service accountservice-agent-manager@system.gserviceaccount.com grants roles to other service agents.This behavior is normal and expected. For details, seeService agents.

Logs for granting the Service Account User role

A principal can gain the same permissions as a service account byimpersonating the service account. To allow a principal to impersonate aservice account, you cangrant the Service Account User role(roles/iam.serviceAccountUser) to the principal for the service account.

The following example shows a log entry for granting the Service Account Userrole to a principal:

{"logName":"projects/my-project/logs/cloudaudit.googleapis.com%2Factivity","protoPayload":{"@type":"type.googleapis.com/google.cloud.audit.AuditLog","methodName":"google.iam.admin.v1.SetIAMPolicy","request":{"@type":"type.googleapis.com/google.iam.v1.SetIamPolicyRequest","resource":"projects/-/serviceAccounts/my-service-account@my-project.iam.gserviceaccount.com"},"resourceName":"projects/-/serviceAccounts/123456789012345678901","response":{"@type":"type.googleapis.com/google.iam.v1.Policy","bindings":[{"members":["user:my-user@example.com"],"role":"roles/iam.serviceAccountUser"}]}},"resource":{"type":"service_account"}}

When yougrant the Service Account Token Creator role(roles/iam.serviceAccountTokenCreator), which allows a principal to createshort-lived credentials, IAM generates a similar log entry.

Logs for granting access to a service account on a resource

You cangrant a role to a service account on a specific resource,which allows the service account to access the resource. If the service thatowns the resource also supports audit logging, then granting a role to theservice account generates an audit log entry. The log entry includes the fieldprotoPayload.authenticationInfo.principalEmail, which identifies the principalthat granted the role to the service account.

The following example shows an audit log entry for granting a role to a serviceaccount for a project. In this example,example-user@example.com granted theOrganization Viewer role (roles/resourcemanager.organizationViewer) to theservice account. TheprotoPayload.serviceName field is set tocloudresourcemanager.googleapis.com, because Resource Manager is theGoogle Cloud service that manages projects. Also, theresource.typefield is set toproject:

{"logName":"projects/my-project/logs/cloudaudit.googleapis.com%2Factivity","protoPayload":{"@type":"type.googleapis.com/google.cloud.audit.AuditLog","authenticationInfo":{"principalEmail":"example-user@example.com"},"methodName":"SetIamPolicy","request":{"@type":"type.googleapis.com/google.iam.v1.SetIamPolicyRequest","resource":"my-project"},"resourceName":"projects/my-project","response":{"@type":"type.googleapis.com/google.iam.v1.Policy","bindings":[{"members":["serviceAccount:my-service-account@my-project.iam.gserviceaccount.com"],"role":"roles/resourcemanager.organizationViewer"}]},"serviceName":"cloudresourcemanager.googleapis.com"},"resource":{"type":"project"}}

Logs for attaching service accounts to resources

If a user has the Service Account User role (roles/iam.serviceAccountUser) ona service account, the user canattach the service account toresources. When code running on the resource accesses Google Cloud services and resources, it uses theservice account attached to the resource as its identity. For example, if youattach aservice account to a Compute Engine instance, and the applications on the instance use aclient library to call Google Cloud APIs,those applications automatically use the attached service account for authentication andauthorization.

This section shows some of the logs that are generated when you attach a serviceaccount to a resource.

Logs for using theiam.serviceAccounts.actAs permission

Attaching a service account to a resource requires theiam.serviceAccounts.actAs permission. When a principal uses this permission toattach a service account to a resource, it generates an audit log.

The following example shows a log entry for a principal using theiam.serviceAccounts.actAs permission to attach a service account to aCompute Engine instance.

{"protoPayload":{"@type":"type.googleapis.com/google.cloud.audit.AuditLog","authenticationInfo":{"principalEmail":"example-user@example.com"},"serviceName":"iam.googleapis.com","methodName":"iam.serviceAccounts.actAs","authorizationInfo":[{"resource":"projects/-/serviceAccounts/sample-service-account@sample-project.iam.gserviceaccount.com","permission":"iam.serviceAccounts.actAs","granted":true,"permissionType":"ADMIN_WRITE"}],"resourceName":"projects/-/serviceAccounts/sample-service-account@sample-project.iam.gserviceaccount.com","request":{"name":"sample-service-account@sample-project.iam.gserviceaccount.com","project_number":"787155667719","@type":"type.googleapis.com/CanActAsServiceAccountRequest"},"response":{"success":true,"@type":"type.googleapis.com/CanActAsServiceAccountResponse"}},"insertId":"vojt0vd4fdy","resource":{"type":"audited_resource","labels":{"project_id":"sample-project","method":"iam.serviceAccounts.actAs","service":"iam.googleapis.com"}},"timestamp":"2024-08-05T21:56:56.097601933Z","severity":"NOTICE","logName":"projects/sample-project/logs/cloudaudit.googleapis.com%2Factivity","receiveTimestamp":"2024-08-05T21:56:56.097601933Z"}

Logs for setting up a Compute Engine instance to run as a service account

If a user has the Service Account User role (roles/iam.serviceAccountUser) ona service account, the user cancreate a Compute Engine virtual machine (VM) instancethat runs as that service account. In this scenario, the user creates the VMinstance with their own credentials, and the request specifies a service accountfor the VM instance to use.

When a user creates a VM instance, Compute Engine creates multiple logentries. The following example shows the first log entry, which identifies theuser who created the VM instance and the service account that the instance uses.In this example, the userexample-user@example.com created an instance that uses theservice accountmy-service-account@my-project.iam.gserviceaccount.com. As aresult, theprotoPayload.authenticationInfo.principalEmail field is set toexample-user@example.com, and theprotoPayload.request.serviceAccounts[0].emailfield is set tomy-service-account@my-project.iam.gserviceaccount.com:

{"logName":"projects/my-project/logs/cloudaudit.googleapis.com%2Factivity","protoPayload":{"@type":"type.googleapis.com/google.cloud.audit.AuditLog","authenticationInfo":{"principalEmail":"example-user@example.com"},"methodName":"v1.compute.instances.insert","request":{"@type":"type.googleapis.com/compute.instances.insert","serviceAccounts":[{"email":"my-service-account@my-project.iam.gserviceaccount.com"}]},"resourceName":"projects/my-project/zones/us-central1-a/instances/my-instance"},"resource":{"type":"gce_instance"}}

Logs for accessing Google Cloud with a service account key

This section shows the log entries you receive when you create a service accountkey, then use the key to access Google Cloud.

Logs for creating a service account key

If you have the Service Account Key Admin role(roles/iam.serviceAccountKeyAdmin) on a service account, you can create aservice account key, then use the key toauthenticate requests to Google Cloud services.

The following example shows a log entry for creating a service account key. Inthis example, the userexample-user@example.com created a key for the service accountmy-service-account@my-project.iam.gserviceaccount.com:

{"logName":"projects/my-project/logs/cloudaudit.googleapis.com%2Factivity","protoPayload":{"@type":"type.googleapis.com/google.cloud.audit.AuditLog","authenticationInfo":{"principalEmail":"example-user@example.com",},"methodName":"google.iam.admin.v1.CreateServiceAccountKey","request":{"@type":"type.googleapis.com/google.iam.admin.v1.CreateServiceAccountKeyRequest","name":"projects/-/serviceAccounts/my-service-account@my-project.iam.gserviceaccount.com"},"resourceName":"projects/-/serviceAccounts/123456789012345678901"},"resource":{"type":"service_account"}}

Logs for authenticating with a service account key

After you create a service account key, you can use the key torequest an OAuth 2.0 access token for a service account, then usethe access token to authenticate requests to Google Cloud services. Ingeneral, the audit logs for those services include the following information:

  • protoPayload.authenticationInfo.principalEmail: The email address of theservice account that the access token represents.
  • protoPayload.authenticationInfo.serviceAccountKeyName: The service accountkey that was used to request the OAuth 2.0 access token. This field identifiesthe service account key by itsfull resource name, whichuses the format//iam.googleapis.com/projects/project-id/serviceAccounts/service-account-email/keys/key-id.
Note: Some Google Cloud services, including App Engine andCompute Engine, do not log the service account key name.

The following example shows an audit log entry for a request to create aMemorystore for Redis instance. The request was authenticated with an OAuth2.0 access token for a service account. In this example, the service account isnamedmy-service-account@my-project.iam.gserviceaccount.com, and the serviceaccount key ID isc71e040fb4b71d798ce4baca14e15ab62115aaef:

{"logName":"projects/my-project/logs/cloudaudit.googleapis.com%2Factivity","protoPayload":{"@type":"type.googleapis.com/google.cloud.audit.AuditLog","authenticationInfo":{"principalEmail":"my-service-account@my-project.iam.gserviceaccount.com","serviceAccountKeyName":"//iam.googleapis.com/projects/my-project/serviceAccounts/my-service-account@my-project.iam.gserviceaccount.com/keys/c71e040fb4b71d798ce4baca14e15ab62115aaef"},"methodName":"google.cloud.redis.v1.CloudRedis.CreateInstance","request":{"@type":"type.googleapis.com/google.cloud.redis.v1.CreateInstanceRequest"}}}

Logs for impersonating a service account to access Google Cloud

This section shows the log entries you receive when you create short-livedcredentials for a service account, then use the credentials to impersonate theservice account and access Google Cloud.

Logs for creating short-lived credentials

If you have the Service Account Token Creator role(roles/iam.serviceAccountTokenCreator) for a service account, you cancreate short-lived credentials for the serviceaccount, then use the credentials to impersonate the service account. Forexample, you might create short-lived credentials to call a Google CloudAPI from an application that does not run on Google Cloud.

IAM can generate audit logs when principals createshort-lived credentials. To receive these audit logs, you mustenable IAM audit logs for Data Access activity.

After you enable IAM audit logs for Data Access activity,IAM generates an audit log entry each time a principalcreates short-lived credentials. The entry includes the following fields:

  • protoPayload.authenticationInfo.principalEmail: The principal that createdthe short-lived credentials.
  • resource.labels.email_id: The service account for which short-livedcredentials were generated.

The following example shows an audit log entry for a request to generate ashort-lived OAuth 2.0 access token. In this example, the userexample-user@example.com created an access token for the service accountmy-service-account@my-project.iam.gserviceaccount.com:

{"logName":"projects/my-project/logs/cloudaudit.googleapis.com%2Fdata_access","protoPayload":{"@type":"type.googleapis.com/google.cloud.audit.AuditLog","authenticationInfo":{"principalEmail":"example-user@example.com"},"methodName":"GenerateAccessToken","request":{"@type":"type.googleapis.com/google.iam.credentials.v1.GenerateAccessTokenRequest","name":"projects/-/serviceAccounts/my-service-account@my-project.iam.gserviceaccount.com"},"serviceName":"iamcredentials.googleapis.com"},"resource":{"labels":{"email_id":"my-service-account@my-project.iam.gserviceaccount.com","project_id":"my-project","unique_id":"123456789012345678901"},"type":"service_account"}}

Logs for authenticating with short-lived credentials

After you create short-lived credentials for a service account, you can use thecredentials to impersonate the service account when you call Google CloudAPIs.

Some of the methods you call might generate audit logs. In general, theselog entries show the following identities:

  • The service account that the short-lived credentials are impersonating
  • The identity that created the short-lived credentials

Note: Some Google Cloud services, including App Engine and Google Kubernetes Engine, do not log the identity that created the short-lived credentials.

For example, suppose that the userexample-user@example.com creates short-livedcredentials for the service accountmy-service-account@my-project.iam.gserviceaccount.com. The user then creates anew Pub/Sub topic, using the short-lived credentials to impersonate theservice account. Pub/Sub generates a log entry that identifiesthe service account, as well as the user who is impersonating the serviceaccount:

{"logName":"projects/my-project/logs/cloudaudit.googleapis.com%2Factivity","protoPayload":{"@type":"type.googleapis.com/google.cloud.audit.AuditLog","authenticationInfo":{"principalEmail":"my-service-account@my-project.iam.gserviceaccount.com","serviceAccountDelegationInfo":[{"firstPartyPrincipal":{"principalEmail":"example-user@example.com"}}]},"methodName":"google.pubsub.v1.Publisher.CreateTopic","request":{"@type":"type.googleapis.com/google.pubsub.v1.Topic","name":"projects/my-project/topics/my-topic"},"resourceName":"projects/my-project/topics/my-topic"},"resource":{"type":"pubsub_topic"}}

Logs for actions taken by service agents

Sometimes, when a principal initiates an operation, aservice 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.

To help you understand the context for a service agent's actions, some service agents include additional details in their audit logs, like the job the action is associated with and the principal that created the job.

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

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

Except as otherwise noted, the content of this page is licensed under theCreative Commons Attribution 4.0 License, and code samples are licensed under theApache 2.0 License. For details, see theGoogle Developers Site Policies. Java is a registered trademark of Oracle and/or its affiliates.

Last updated 2025-12-15 UTC.