Key-less entry with GCP Service Accounts and Impersonation

Stop downloading service account keys. Here are three quick guides demonstrating key-less access to GCP.

This is a short pratical guide covering three common use cases and how to use service accounts as a user more securely.

  1. Using gcloud as a service account
  • 👥 Audience: Beginner — Intermediate

Working with Service Account Impersonation

Service account impersonation is a secure way to provide user RBAC to service accounts without distributing physical keys. This is a GCP native approach to user accessed service accounts and provides a higher level of transparency and control. Impersonation requires the user to first authenticate as themselves before being granted access to the service account, and only if they have the adequate role to do so.

Learn more about the Zero Trust model

Install the gcloud SDK

Becoming familiar with the gcloud CLI tool will allow you to rapidly access and retrieve data across all your projects and scale and even develop automated tools to increase your productivity.

If you haven’t already, download the gcloud SDK here.

Authenticate as yourself

With the gcloud SDK installed, authenticate using your user account:

gcloud init

It will ask you to set a default project, and a default zone/region. These can be changed later but are also inconsequential to the exercise.

Configure the Service Account

The user account should have the Service Account Token Creator role on the required service account, this will allow you to impersonate the service account. This is an additional role regardless of any existing role you have (Owner, Editor, etc).

You can apply the role from the console via IAM & Admin > Service Accounts. Locate the service account and add your user account with the Token Creator role. You can also apply this role at the project level to propagate it to all service accounts.

Example 1. Using gcloud as a service account

The CLI is a pathway to many abilities some consider…unnatural

There could be a situation where you’d like to impersonate a service account to execute gcloud CLI commands with a different level of access.

After authenticating as yourself in the gcloud CLI, impersonate the required service account:

gcloud config set auth/impersonate_service_account <service-account>

Remember, your user account requires the Token Creator role.

Every command you now execute via the gcloud CLI will be done using the service account’s level of access.

# list projects the service account can access
gcloud projects list

You can change service account using the same command. To unset the impersonation and revert back to your user account, use the following command:

gcloud config unset auth/impersonate_service_account

Example 2. Working with Terraform locally

Use OAuth with service account impersonation! Terraform is smart enough to find different types of credentials. Not only can you hardcode service account impersonation into your Terraform, the simplest way to is to use OAuth.

After authenticating, impersonate the required service account:

gcloud config set auth/impersonate_service_account <service-account>

Remember, your user account requires the Token Creator role.

The next step is to set an enviornment varable for Terraform to find and use. The following command saves an OAuth token to a known environment variable. Because we have impersonated the service account it will save the service accounts OAuth token.

export GOOGLE_OAUTH_ACCESS_TOKEN=$(gcloud auth print-access-token)

You can now execute Terraform commands as the service account without needing a physical key.

terraform plan

Note: This token only lasts for an hour, therefore you will need to periodically refresh it. You could also create your own helper scripts to automate the refresh before running any commands.

Example 3. Running local scripts and code

Use programmatic service account impersonation! If the scripts are intended to only be run locally you can programmatically impersonate the required service account.

Ensure you’ve authenticated to gcloud beforehand:

gcloud init

You don’t need to impersonate via the CLI for this one, instead do it programmatically within your code.

Important: If you impersonate at this stage, the next step will not create the correct credential file as you will be executing the command as the service account, not your own user account. While the file is valid, it is not accepted by Googles SDKs currently.

The final step is to allow scripts to pickup our user credentials:

gcloud auth application-default login

This creates a local file to allow programmatic access to our gcloud user credentials.

You can use the above steps as well if you wanted to work with Terraform using your own user account instead of a service account.

The below example in Python shows how to list buckets in a project using impersonated credentials:

Lines 31-40 show the flow, we fetch our user account credentials set my gcloud. Because we have the token creator role we can use our credentials to request the service account credentials. We then pass the impersonated credentials in to our list_buckets() function instead of our own.

Impersonation is Better!

“I make the user access silky and smooth”

Admin Activity Logs

By utilising service account impersonation we achieve a greater level of transparency and control. From the host project of the service account we can view the Admin Activity logs of users accessing the service account. This is not possible with physical key distribution

User Access Management

Users can be granted access by simply providing them the Token Creator role at the appropriate scope (Organisation, Project, Resource). Access can be easily revoked by removing the role. This is far superior to manually generating keys and distributing them. To revoke a users access you would need to either provide individual keys that can be revoked, or rotate the a key for every user and potentially cause a breaking change.

Even after revoking a users key, it does not prohibit them from aquiring someone elses key and using it. RBAC provides a granular and cloud native approach to resource access that is centrally managed from the GCP console.

Enhanced Security Posture

With RBAC to service accounts in place you can be rest assured access to service accounts remain completely under the cloud adminstrators control. This greatly improves the security posture your environment and mitigates any potential risk of intrusion from unauthorised users. The only way for someone to gain access to service account would be via a compromised user account (this can also be mitigated through MFA and various services).

Further Reading

Cloud Consultant, developer, problem-solver. Interested in learning new things and sharing what I know.