Also read  - Service Accounts in GCP and a 2 minute Security Solution for GCP Environments

Service Accounts as an  alternative to embedding app credentials

Service accounts are robo accounts that can be used in place of IAM user credentials or app credentials.  They are particularly useful for an app calling Google APIs - without the need to

  • embed secret keys in your instance
  • embed user credentials in your instance
  • embed keys or credentials in your VM image
  • embed keys or credentials in your app code

They live OUTSIDE the VM scope and the app scope - but the scope of the Service account is inherited by the application and the underlying VM on which it is running.

Custom SA versus Default SA

Default SAs are way too permissive. They may be okay in DEV environments (even there, be careful , as often DEV environments are coupled to networking resources in NON DEV environments - especially through  Host VPC and Service Projects).

SA Constraints at the Org and Project Level

At the org level - Disable automatic role grants to default service accounts
At the project level - Disable service account creation and Disable service account key creation




Need an experienced AWS/GCP/Azure/DevSecOps Professional to help out with your Public Cloud Strategy? Set up a time with Anuj Varma.