GCP Service Account 101

on GCP, IAM, and 101

Service Accounts are identities used for authenticating infrastructure and resources, typically for non-human entities. Service Accounts do not utilize passwords. While you have the option to generate and export a private key for a service account, it’s generally unnecessary and can pose a security risk in most cases. The only valid scenario where generating and exporting a private key may be necessary is to enable external integrations in instances where OIDC is not supported.

Service Accounts as Resources

Service accounts are created within and associated with a specific project. Think of a service account as having a ‘home’ project, similar to how a compute instance or a storage bucket ‘resides’ in a project within the resource hierarchy.

Similar to other resources, you can use the setIAMPolicy method to attach IAM policies to a service account. IAM policies for a service account typically include permissions such as:

  • generate an OAuth or OIDC token for the service account (impersonate)
    • (.getAccessToken) (.getOpenIdToken)
  • attach a service account to a resource.
    • (.actAs)
  • generate keys for the service account.
    • (iam.serviceAccountKeys.create)
  • manage the service account.
    • (.create) (.delete) (.setIamPolicy)

Service Accounts as Identities

In GCP, service accounts, like other identity types such as users and groups, can be included as members in IAM Policies and assigned roles at any level within the resource hierarchy. Service accounts are not restricted to being granted roles within their home project. Similar to users and groups, service accounts can have cross-project permissions or even have access to resources in other organizations.

Attaching a Policy to a Service Account

When binding a policy to a service account, the principal granted permissions (the WHO) can be another service account. In fact, it can be advantageous to establish a pattern where a service account is granted permissions to impersonate another service account.

In such scenarios, the service account performing the impersonation is the WHO, functioning as an principal. Meanwhile, the service account being impersonated serves as the target resource.