This page shows examples of the audit logs that are generated when you manage or use a service account.
For more information about enabling and viewing audit logs, see IAM 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 a service 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 are related to service accounts.
Logs for granting the Service Account User role
A principal can gain the same permissions as a service account by
impersonating the service account. To allow a principal to impersonate a
service account, you can grant 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 User role 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 you grant the Service Account Token Creator role
(roles/iam.serviceAccountTokenCreator
), which allows a principal to create
short-lived credentials, IAM generates a similar log entry.
Logs for granting access to a service account on a resource
You can
grant a role to a service account on a specific resource,
which allows the service account to access the resource. If the service that
owns the resource also supports audit logging, then granting a role to the
service account generates an audit log entry. The log entry includes the field
protoPayload.authenticationInfo.principalEmail
, which identifies the principal
that granted the role to the service account.
The following example shows an audit log entry for granting a role to a service
account for a project. In this example, example-user@example.com
granted the
Organization Viewer role (roles/resourcemanager.organizationViewer
) to the
service account. The protoPayload.serviceName
field is set to
cloudresourcemanager.googleapis.com
, because Resource Manager is the
Google Cloud service that manages projects. Also, the resource.type
field is set to project
:
{
"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
) on
a service account, the user can attach the service account to
resources.
When code running on the resource accesses Google Cloud services and resources, it uses the
service account attached to the resource as its identity. For example, if you attach a
service account to a Compute Engine instance, and the applications on the instance use a client library to call Google Cloud APIs,
those applications automatically use the attached service account for authentication and
authorization.
This section shows some of the logs that are generated when you attach a service account to a resource.
Logs for using the iam.serviceAccounts.actAs
permission
Attaching a service account to a resource requires the
iam.serviceAccounts.actAs
permission. When a principal uses this permission to
attach a service account to a resource, it generates an audit log.
The following example shows a log entry for a principal using the
iam.serviceAccounts.actAs
permission to attach a service account to a
Compute 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
) on
a service account, the user can
create a Compute Engine virtual machine (VM) instance
that runs as that service account. In this scenario, the user creates the VM
instance with their own credentials, and the request specifies a service account
for the VM instance to use.
When a user creates a VM instance, Compute Engine creates multiple log
entries. The following example shows the first log entry, which identifies the
user who created the VM instance and the service account that the instance uses.
In this example, the user example-user@example.com
created an instance that uses the
service account my-service-account@my-project.iam.gserviceaccount.com
. As a
result, the protoPayload.authenticationInfo.principalEmail
field is set to
example-user@example.com
, and the protoPayload.request.serviceAccounts[0].email
field is set to my-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 account key, 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 a
service account key, then use the key to
authenticate requests to Google Cloud services.
The following example shows a log entry for creating a service account key. In
this example, the user example-user@example.com
created a key for the service account
my-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 to request an OAuth 2.0 access token for a service account, then use the access token to authenticate requests to Google Cloud services. In general, the audit logs for those services include the following information:
protoPayload.authenticationInfo.principalEmail
: The email address of the service account that the access token represents.protoPayload.authenticationInfo.serviceAccountKeyName
: The service account key that was used to request the OAuth 2.0 access token. This field identifies the service account key by its full resource name, which uses the format//iam.googleapis.com/projects/project-id/serviceAccounts/service-account-email/
.keys/key-id
The following example shows an audit log entry for a request to create a
Memorystore for Redis instance. The request was authenticated with an OAuth
2.0 access token for a service account. In this example, the service account is
named my-service-account@my-project.iam.gserviceaccount.com
, and the service
account key ID is c71e040fb4b71d798ce4baca14e15ab62115aaef
:
{
"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-lived credentials for a service account, then use the credentials to impersonate the service 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 can
create short-lived credentials for the service
account, then use the credentials to impersonate the service account. For
example, you might create short-lived credentials to call a Google Cloud
API from an application that does not run on Google Cloud.
IAM can generate audit logs when principals create short-lived credentials. To receive these audit logs, you must enable 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 principal creates short-lived credentials. The entry includes the following fields:
protoPayload.authenticationInfo.principalEmail
: The principal that created the short-lived credentials.resource.labels.email_id
: The service account for which short-lived credentials were generated.
The following example shows an audit log entry for a request to generate a
short-lived OAuth 2.0 access token. In this example, the user
example-user@example.com
created an access token for the service account
my-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 the credentials to impersonate the service account when you call Google Cloud APIs.
Some of the methods you call might generate audit logs. In general, these log entries show the following identities:
- The service account that the short-lived credentials are impersonating
- The identity that created the short-lived credentials
For example, suppose that the user example-user@example.com
creates short-lived
credentials for the service account
my-service-account@my-project.iam.gserviceaccount.com
. The user then creates a
new Pub/Sub topic, using the short-lived credentials to impersonate the
service account. Pub/Sub generates a log entry that identifies
the service account, as well as the user who is impersonating the service
account:
{
"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, 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.
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 the serviceDelegationHistory
field of the audit log,
which is nested in the authenticationInfo
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, suppose example-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 a
serviceDelegationHistory
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
- Configure and view the audit logs for IAM.
- Get more information about Cloud Audit Logs.
- Learn about service accounts.
- Create and manage service accounts.
- Create short-lived credentials for impersonating service accounts.