Service Account

A service account is a special kind of account used by an application or compute workload, rather than a person

• A service account is identified by its email address
• The service account is used as the identity of the application, it can be attached to a Compute Engine VM
• The service account's roles control which resources the application can access.

Compared to User Account

• Service accounts do not have passwords, and cannot log in via browsers or cookies.
• Service accounts are associated with public/private RSA key pairs that are used for multiple purposes, such as signing data.
• You can let other users or service accounts impersonate (simulate) a service account.

Lifecycle

Project locked: Each service account is located in a project. After you create a service account, you cannot move it to a different project.

• When a service account is in one project, and it accesses a resource in another project, you usually must enable the API for that resource in both projects.

Service account impersonation

predefined roles that allow a principal to impersonate a service account

• Service Account User roles/iam.serviceAccountUser
  • This role also allows principals to attach a service account to a resource
• Service Account Token Creator roles/iam.serviceAccountTokenCreator
  • allow principals to create short-lived credentials for service accounts
  • allow to use the --impersonate-service-account flag for the Google Cloud CLI.
• roles/iam.workloadIdentityUser: for GKE service account

How to

• allow a principal to impersonate multiple service accounts
• allow a principal to impersonate a single service account

Attaching(associating) a service account to a resource: the automatical impersonation

• Immutable: beside Compute Engine as an exception, after the resource is created, you cannot change which service account is attached to the resource.

impersonation across projects

• It is not a best practice, since it breaks the project isolation principal.