Impersonate Users With Google Cloud Service Accounts

With great power comes great responsibility

Published in

Google Cloud - Community

4 min readSep 2, 2018

As Sal Rashid describes in his article, the IAM serviceAccountActor role enables another user or service account to impersonate a service account (this role has now been superseded by the serviceAccountUser role).

But what if you want to do the inverse, ie. impersonate a user with a service account? This is a common use case in a service-based architecture: services will perform actions (eg. store a record, retrieve a blob) on behalf of users.

First, a little background on why you might want to impersonate the user rather than just use the service account for authorization. Doing the latter is simple, but violates least-privilege (it’s like building a mobile application which just uses API keys) and breaks down if users will also have direct access (eg. upload/download objects to/from Google Cloud Storage, or run queries on BigQuery) to the Google Cloud Platform managed resources with which the services are interacting: there is evidently a mis-match between permissions based on service accounts and direct user access.

You can address this mismatch (with the exception of Google Cloud Storage object ACLs, which are in part based on the user uploading the object) by explicitly setting user-based permissions, but this adds both processing and administrative overhead. Which brings us to user impersonation.

User Impersonation

You can enable a service account to impersonate a managed user, ie. act on behalf of a Cloud Identity, via domain-wide delegation of authority (ignore the legacy G Suite branding; this applies to Cloud Identity APIs as well). This is the approach we’ll focus on in this article.

This addresses a couple of the issues with service account based authorization mentioned above:

Assets created by your application need to be ACL’d to the end user. You could manage this manually yourself via the IAM APIs, but user impersonation takes care of it automagically.
Google Cloud Storage object ACL’s are in part based on the user uploading the object; user impersonation ensures that these ACLs reflect the user rather than the service account.
Your application needs to expose the appropriate assets to your customer’s users based on the their identity. Managing this manually would require that you essentially build an ACL layer within your application; user impersonation makes it happen automagically.

Limitations

So with all this magic in the air, why wouldn’t you do this, congratulate yourself on a job well done, and go home? There are a couple of reasons:

Least privilege

As you may have guessed from the “domain-wide” naming, user impersonation can be scoped down to GCP API methods, but not to users or resources within a domain. This means that a service account can access all resources within its method scope (eg. read Google Cloud Storage), so the least privilege issue persists.

This is sort of ok if you’re managing your own users and data, though not great.
It’s worse if you’re building SaaS applications which require access to customer-owned resources, since many of their users’ assets are confidential to the customer, ie. not meant to be shared with your application.

Audit

As far as Google Cloud Platform is concerned, once authentication has been established, the actual user is creating/accessing the resources. This means that audit trails, billing, quotas, etc. are all linked to the user rather than your application or its service accounts.

This merits particular attention since the broad scope of user impersonation calls for powerful compensating controls; robust governance processes and automation can help.

Mitigation

VPC Service Controls (in private beta) can help mitigate the least privilege concerns, though they do incur an administrative overhead tax.

They enable you to define a network-based security perimeter around Google Cloud Platform resources such as Cloud Storage buckets to constrain data within a Virtual Private Cloud (VPC) and help mitigate data exfiltration risks.

You and your customers can put resources in secure zones and establish IP-based restrictions on access so confidential information isn’t shared with your application.

There is a key caveat: VPC Service Controls are fail-open rather than fail-closed, so data which isn’t explicitly in a VPC security zone will be available across VPC boundaries. Robust governance processes and automation can help mitigate this risk.