How do I impersonate a GCP service account when running the SDK locally? Like how I can on AWS by assuming iam roles

Question

One thing I dislike about Google Cloud Platform (GCP) is its less baked-in security model around roles/service accounts.

Running locally on my laptop, I need to use the service account's key specified in a JSON file. In AWS, I can just assume a role I have been granted access to assume (without needing to carry around a private key). Is there an analogue to this with GCP?

EDIT

This was a poorly worded question. My really annoyance was more related to the fact that the SDK and gcloud cli have different auth methods and how you could globally impersonate a GSA with the CLI, but not the SDK.

In AWS you setup your cli and SDK creds the same way and can set an env var to have the cli AND SDK both assume a role instead of your user account.

In my answer I included new-ish commands that provide similar functionality. Users can now globally impersonate a GSA for their app code to use without generating json keys- or modifying the code in any way.

Answer 1

At some point Google finally added the feature I was actually looking for in my question, which was a little vague. I'm adding an edited to make it clearer.

There is now much better parity with the cli and SDK wrt to impersonation.

You can now do the following:

1. Setup your user creds for the cli AND SDK (default app creds) in one step:
   • gcloud auth login --update-adc
2. Impersonation a service account for SDK auth:
   • gcloud auth application-default login --impersonate-service-account my-gsa@myproject.iam.gserviceaccount.com

This use to not be possible. I feel like this is very poorly documented for new users to the platform. Most users still seem to think the only way to run your app code locally in the security context of a GSA is to modify the code itself or generate a static json key and thats not the case anymore.

Also, please chime in if there is any info I'm missing or if there are more commands/tooling for this sort of thing available now.

Answer 2

Google Cloud has exactly the same thing as AssumeRole, it's called Impersonate.

See https://cloud.google.com/docs/authentication/use-service-account-impersonation

Same as with AWS -- you still need to authenticate (using credentials or SSO or whatever), otherwise cloud doesn't know who you are, and then:

1. If your identity has permissions to AssumeRole/Impersonate, and
2. If that Role (AWS) / ServiceAccount (GCP) allows to be impersonated by you

then your identity can act as other assumed/impersonated identity.

Answer 3

I am going to try and answer this. I have the AWS Security Specialty (8 AWS certifications) and I know AWS very well. I have been investing a lot of time this year mastering Google Cloud with a focus on authorization and security. I am also an MVP Security for Alibaba Cloud.

AWS has a focus on security and security features that I both admire and appreciate. However, unless you really spend the time to understand all the little details, it is easy to implement poor/broken security in AWS. I can also say the same about Google security. Google has excellent security built into Google Cloud Platform. Google just does it differently and also requires a lot of time to understand all the little features / details.

In AWS, you cannot just assume a role. You need an AWS Access Key first or be authenticated via a service role. Then you can call STS to assume a role. Both AWS and Google make this easy with AWS Access Keys / Google Service Accounts. Whereas AWS uses roles, Google uses roles/scopes. The end result is good in either platform.

Google authentication is based upon OAuth 2.0. AWS authentication is based upon Access Key / Secret Key. Both have their strengths and weaknesses. Both can be either easy to implement (if you understand them well) or a pain to get correct.

The major cloud providers (AWS, Azure, Alibaba, Google, IBM) are moving very fast with a constant stream of new features and services. Each one has strengths and weaknesses. Today, there is no platform that offers all the features of the others. AWS today is ahead both in features and market share. Google has a vast number of services that outnumber AWS and I don't know why this is overlooked. The other platforms are catching up quickly and today, you can implement enterprise class solutions and security with any of the cloud platforms.

Today, we would not choose only Microsoft or only Open Source for our application and server infrastructure. In 2019, we will not be chosing only AWS or only Google, etc. for our cloud infrastructure. We will mix and match the best services from each platform for our needs.

Answer 4

As described in the Getting Started with Authentication [1] page, for service accounts it is needed the key file in order to authenticate.

From [2]: You can authenticate to a Google Cloud Platform (GCP) API using service accounts or user accounts, and for APIs that don't require authentication, you can use API keys.

Service and user accounts needs the key file to authenticate. Taking this information into account, there is no manner to locally authenticate without using a key file.

Links:

---

[1] https://cloud.google.com/docs/authentication/getting-started [2] https://cloud.google.com/docs/authentication/