Google Cloud Platform identity is a large domain of the GCP Security Engineer exam and the emphasis also expands on the use of Service Accounts. Similar to Azure environments service accounts by abstraction come in the form of being used for various services to access other resources via REST APIs. Notably these resources without proper oversight and management can pose a risk to an organizations attack surface. While service accounts are commonly used for access to other underlying services the monitoring of this and associated permissions needs to be scrutinized in fine detail when using elevated operations on the resources in your project.
Common Patterns
Most entrants to using any cloud services starts with the consumption of virtual servers or “virtual machines” these are denoted in Google Cloud as Compute Engine, the service itself represents a virtual machine. Underlying this virtual machine is using a service account which can be default “highly privileged” as a editor that can visualized as below diagram where the Compute Engine might have to access storage buckets to display files that are static in nature.
When you start to parse through what are default access and what is full access I like to think of the roulette concept you’re wagering on a large surface on full access being the most privileged. Ideally a sweet spot is identifying what the machines/groups of services need access to enable this at least permissive. From a practical perspective many that read this might say how does this scale? In most cases, you have unbound limitations of privileges in the use of roles that are pre-packaged for operations such as Cloud Function Admin one must decide if we codify this via terraform we’d likely want repeatable patterns. Such as a web application that will access a specific storage bucket to retrieve static files or a database that we want only read-only these parameters can be mapped to least permissive as a boundary.
Where does impersonation come into play?
Impersonation for as the word implies is the use of the –impersonate-service-account flag on the command line that takes the underlying service accounts permissions such as “Vertex AI Operator” and allows a end user with the permissions of “Service Account Token Creator Role” to assume the permission as shown below this visualization is to help convey this.
Service Account B is assigned a permission and used for operations related to Vertex AI as a resource. The end user doesn’t have the privileges required to perform a test on this service and doesn’t want to request additional permissions for a short-lived operation that touches an application.
For the use of impersonation you’ll need the Service Accounts Credentials API enabled on your GCP Project. Then to use impersonation the user or group that uses this type of authorization must have serviceAccountUser assigned along with service Account Token Creator.
For this to work we start by grabbing our service account that has the assigned permissions our principal wants to use and elevate to. We generate a key ensure you delete this after the demo in the Service Account -> Account -> Keys
Now ensure that the key is stored somewhere offline that also will be disabled if you are following along this has to be referenced in the API call.
# ensure project is set
gcloud config set project <project-id>
gcloud config set auth/impersonate_service_account <svc acc email> --key-file=<file>After this is complete you’ll see a banner saying all API calls are surfaced through the impersonated service account.
Now we can also disregard setting the credential and issue a command line of the command we are trying to run with the impersonation flag.
gcloud storage buckets list --impersonate-service-account=<svc-acct>
Redacting the rest of the sensitive data we are accessing from the service account the storage account we didn’t have access to as a principal. This is logged under the service account and the warning letting you know that its executed as such.
Alternatives
If you’re trying to achieve the same level of access but want to ensure your Service-credentials are short-lived you can use the following methods such as issuance of a ‘access token’. This can work with OpenID Connect (OIDC) ID tokens, Self-signed JSON Web Tokens (JWT), Self-signed binary blobs. This method still requires two identities to accomplish but once a token is generated it can’t be refreshed without repeating the process as it will expire.
- Caller Service Accounts – Applications that is calling for the short-lived credential
- Privilege Bearing Service Account – Privilege account with IAM roles needed for the short-lived credential (this is where the token is created)
These accounts can’t be the same such as ‘self-impersonation’ the documentation calls that out in this section.
Example command in the cloud shell of this being completed.
gcloud iam service-accounts add-iam-policy-binding <privileged> \
--member=serviceAccount:<caller-sa> --roles=roles/iam.ServiceAccountTokenCreator --format=jsonWhile more to this method are described in documentation ideally as shown earlier we want to shy away from generating Service Account Keys and use more short-lived credentials. Most Cloud Service Providers including GCP, Azure and AWS will recommend use of short-lived credentials for operations to minimize the risk if a key is exposed and has access to highly privileged accounts. A rule of thumb I’ve always followed if some level of access has “Write” privileges on a service you want to minimize the ability of this to the need-to-access methods. Additionally if you want your “principals” in your organization constrained to a boundary you can construct a Principal Access Boundary policy which confines the users to specific resources, folders, projects etc.
Best Practices
While this won’t encompass the whole gambit of best practices at a high level consider the following on Service Accounts in GCP.
- Continuously monitoring unused service accounts (this is residual risk you can minimize by disabling the unused accounts) – GCP recommends disablement before outright deletion
- Single-purpose Service Accounts – each service account represents a use for your organization such as logging, this helps identify quickly in the log explorer actions taken on behalf of the service account. This can exponentially grow as your scaling applications that are using a single service account. Every application likely has a different lifecycle to consider, also note Editor role is by default service account on Compute Engine and App Engine. This is highly permissive ensure you limit this access and not opt in default settings.
- Don’t use groupings for granting service accounts access to resources – this might on the surface seem like less overhead however each application likely has a specific resource and resources alike that they might operate in overtime this assignment can be creep of overprivileged to resources and subsets of resources. Leverage direct grant service accounts for the access of resources that are needed. (Might be tedious but your minimizing risk)
- Enable data access logs for IAM APIs – in the event of trying to reconstruct what a service has done on behalf of a service account the use of Data Access Logs for the recording of Impersonation events you must also enable data access logs for the following API’s
- Identity and Access Management (IAM) API – Google Cloud Projects that contain service accounts.
- Security Token Service API – in all GCP Projects that contain workload identity pools
Summary
Identity in the cloud is tricky without a plan that is detailed and reviewed the amount of risk can be exponential. Plan wisely on when to adopt specific practices related to your organization risk appetite but also veer with caution in most cases I’ve seen any default settings on their own while in practice for learning the platform are rarely recommended for production. Google Cloud also includes best practices on Service Accounts leveraged in deployment pipelines for your DevOps team. Measuring the risk of any of these topics is on-going however with some due diligence you can stay ahead of minimizing the attack surface of the control plane and resources your organization is consuming.