Service accounts are wonderful tools. They enable us to have role based access control without the need of human intervention. It’s not hyperbole to say that the internet is run by service accounts.
A service account is a type of account intended to represent a non-human user that needs to authenticate and be authorized to access resources, data, and perform actions on our behalf.
To authenticate a service account you need to use a service account key, a file provided to you by the vendor to include in scripts and processes. That key file has with it all the permissions and access of the service account it was created for. In the case of my last blog post, the account has the ability to create/modify/destroy any compute instance or any networking resource.
All of this sounds fine until you consider what would happen if an attacker got control of that key file; what about the rest of the service account keys you (or your colleagues) may have on disk.
An attacker gaining control of a service account can enable them to move laterally across your cloud infrastructure or even elevate their privileges to access higher security resources.
Taking into consideration an attacker, things can escalate quickly and all precautions that were taken in securing a cloud environment are now compromised.
There are a few ways to keep a service account key safe
- Encrypt it and decrypt as needed
- Centralize key storage and apply heavy permissions
- Keep it on a removable usb stick
These solutions will work but they add complexity and still require the user protect the keys. A better solution would be to not have keys to manage at all!
Introducing, Service Account impersonation!
There are grantable roles in Google Cloud Platform that allow accounts to perform actions as if they were that Service Account. In GCP we can add an IAM Policy to the project, folder, or organization that will grant users or groups the ability to act as any Service Account. If you want to limit the impersonation to a specific SA, we would add the IAM Policy to the SA itself and not a parent object.
The three predefined roles to allow a user to impersonate a service account are:
Service Account User (roles/iam.serviceAccountUser): Allows members to indirectly access all the resources that the service account can access. For example, if a member has the Service Account User role on a service account, and the service account has the Cloud SQL Admin role (roles/cloudsql.admin) on the project, then the member can impersonate the service account to create a Cloud SQL instance.
Service Account Token Creator (roles/iam.serviceAccountTokenCreator): Allows members to impersonate service accounts to create (OAuth 2.0) access tokens, sign JSON Web Tokens (JWTs), and sign binary blobs so that they can be used for authentication.
Workload Identity User (roles/iam.workloadIdentityUser): Allows members to impersonate service accounts from GKE workloads. This role cannot be granted on individual service accounts, but can be granted on a project, folder, or organization.
For programatic purposes, best practices suggest using Service Account Token Creator role as Service Account User allows full access to all service account resources and may be too permissive.
Any tools that relied on the service account may need to be reconfigured to utilize access tokens associated with the currently authenticated user rather than a key file but we have eliminated the need for user to act as a key file custodian and all the potential complexity that adds to daily processes if done securely.
In a previous post I discuss deploying resources using terraform we use a service account key, if you followed that guide take a look at this gist to see what a google token provider block using a token provider looks like vs a provided service account key.
If you’re currently using service account key files in your environment I hope this post has convinced you to consider migrating away from the practice. As your environment grows in size and complexity so does the attack surface.
Small changes in practice can have huge operational benefit!