Audit logs for service accounts

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.

Granting roles

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

Granting the Service Account User role

A member can gain the same permissions as a service account by impersonating the service account. To allow a member to impersonate a service account, you can grant the Service Account User role (roles/iam.serviceAccountUser) to the member for the service account.

The following example shows a log entry for granting the Service Account User role to a member:

{
  "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:srini@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 member to create short-lived credentials, IAM generates a similar log entry.

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 member 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, julia@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": "julia@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"
  }
}

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 jackie@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 jackie@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": "jackie@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"
  }
}

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.

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 sam@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": "sam@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"
  }
}

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"
    }
  }
}

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.

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 members 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 member creates short-lived credentials. The entry includes the following fields:

  • protoPayload.authenticationInfo.principalEmail: The member 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 amara@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": "amara@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"
  }
}

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 yoon@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": "yoon@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"
  }
}

What's next