Also read - is Terraform a good tool for managing GCP IAM resource creation? 

Service Accounts  - Notes from GCP production 

Need Help with your GCP Project?

Contact a certified professional GoogleCloudArchitect today.

Introduction

If you are part of the IAM provisioning team for Google Cloud resources, you will have to deal with multiple requests for creating and managing service accounts. These requests range widely in their scope and access requirements. This post helps deal with some of the intricacies - and what type of sevice account should you (the IAM provisioning team) provide the requesters (typically infrastructure teams and application teams).

gcp service accounts
gcp service accounts

Why do we need service accounts?

Think of server to server communication (typically, calling APIs). This requires IAM credentials on the GCP side - which has access to the APIs that need to called / resource that needs to be accessed. This is where service accounts play a crucial role - once defined, the private key can be downloaded and used on the calling server (e.g. a Service Now instance that needs to talk to GCP).

What about desktop to Server communication?

Same difference. Actually - computer to computer communication is the main purpose of service accounts. This could also translate to computer to service (e.g. GCP storage service) communication. However, if you think about it, behind every service is a compute artifact.

How many Service Accounts do you need?

The short answer is - base it on the type of requests from application teams. E.g. request types include:

  1. Request to create VMs via automation-
    1. This is a high level Service Account Request - for Infrastructure and security level resources (e.g. for creating resources and for applying security policies to the resources). These should be few and far in between. No keys should be allowed for these.
  2. Request to enable a service for an application. e.g. - enable Dataproc.
    1. This is a fairly limited, self contained request. It is best to use a pre-defined service account here (e.g. a Dataproc specific SA that has just dataproc roles assigned). When the service is enabled, you get the option of attaching a service account. use either the default - or a custom SA for that purpose. So - a set of pre-defined service accounts per service should be made available by the IAM provisioning team.
  3. Request to access a resource  - e.g. a dataset within bigquery.
      1. This is an even more restricted request than the one above. Simply ceate a new custom Service A that grants access to just that resource.

Infrastructure and Security Scoped Service Accounts on GCP -

For infrastructure and automation

  • No Keys allowed
  •  can provision resources, including entire apps
  •  levels it can exist at - Project Level, Org Level, Folder level
  • e.g. - [email protected]

Application Scoped Service Accounts

  •   can call all services on behalf of the app
  •   levels it can exist at - Project Level
  •   Keys allowed - rotate 90 days
  • e.g. - [email protected]

Specific GCP Service Scoped

  •  Can only call a specific service on behalf of an app
  •   levels it can exist at - Project Level
  •   Keys allowed - rotate 90 days
  • e.g. - [email protected]

How many Service Accounts should you provision?

One approach is - to have just two. One for automation within a project. and one for the application hosted within the project.

On Initial Project creation, it is crucial to ensure that the SA is provisioned for a single app (not multiple apps). If not, then you can still do a single SA PER Service within that App - instead of per PER app.

Bare minimum required at project level / folder level?

If we create a project that contains a single service account - that Service Account will need to have IAM.projectAdmin role assigned. This way, it can control IAM on the folder (create more users etc.). Ideally, if you do this at a folder level,  new projects can be created by the SA (like an automated IAM admin level SA for that folder).

The two must have org constraints for service accounts and projects

Constraint 1 - applicable to new projects on creation - disallow access to the 12 default GCP services (storage, compute etc.)

Constraint 2 - applicable to new service accounts on creation - disallow automatic API grants to the default SA. (i.e. restrict the default SA credentials)

What if I need to group multiple service accounts?

Use the tips here

Default Service Account created at Project Level

The app-level default service account is the auto-created PROJECT_ID @appspot.gserviceaccount.com service account. You can assign another service account to act as the app-level default service account using Google Cloud CLI, Google Cloud console, or Admin API.

Find all unused service accounts in a folder,  project, org

gcloud recommender insights list \ 
        -- folder='myfolder' 
	--insight-type=google.iam.serviceAccount.Insight \
	--location=global \
	--filter=insightSubtype=SERVICE_ACCOUNT_USAGE \
	--format=json

Appendix A - Service Accounts always come with a key...?

This is a common misconception. Service accounts can be without any JSON keys. e.g. - use a Cloud Build Trigger to create a keyless service account. The trigger itself would need to be assigned the SA User role.