Using Short Lived Credentials for GCP

With great powers comes great Responsibilities

Introduction

Google Cloud Platform (GCP) provides an easy way to generate Service Account Keys, which is the most preferred way to authenticate your Automation Scripts to GCP, if they are NOT running on GCP infrastructure.

But, ensuring the safety of this key becomes “user’s responsibility”, under the Cloud Provider’s Shared Responsibility Model. And that is where all the headache starts.

Problems

• If ever this key gets uploaded to public repositories or ends up being shared to people it’s not meant for, can leave your account compromised.
• Since you automation scripts would also be using it, it would be difficult to highlight that this key is also being used by un-authorised users.

Solution

There are multiple ways to solve this problem. But for the course of this interaction we shall consider “SHORT LIVED CREDENTIALS”.

If you have no-one to proctor an exam, take an open book exam !!

If you can not guard a secret, the best way is to ensure that there are no secrets at all. That way even if something gets leaked, it’s not powerful enough to cause any damage.

Short Lived Credentials

Short lived credentials, are credentials which are valid only for a few hours. In terms of authentication, they are as good as the service account’s Keys itself.

There are many other advantages this approach has:

• All users of your scripts do not have to understand complex auth mechanisms.
• There are minimal changes required to your scripts, mostly some helper functions or alias setting can get the job done.
• There are ways to implement this any tool that you might be using for interacting with GCP: CLI , REST APIs, SDKs, terraform, etc.

We would in a while discuss ways on how you can use them in various use cases.

What shall happen behind the scenes

Design Diagram: Your scripts have access to a key with limited permissions. This just helps you create short lived credentials in context of some other service account.

1. There are two service accounts sa-1-low@…. and sa-2-high@….
2. sa-2-high has all the permissions that you need for your scripts to run. But, it has no keys.
3. sa-1-low has permissions to impersonate credentials on behalf of sa-2 (only). (Similar to AWS’s assume role). But has no other permissions.
4. You have a key for sa1-low, which you use to get temporary credentials for sa-2-high and run all your tasks.

Setting Things Up

Automatically Set Up Everything

You can use the below command to automatically set up everything for you. Just open a Cloud Shell and run the below command.

curl https://gist.githubusercontent.com/anchitarnav/444b35c9b00ed4c31c2f25c5984b15df/raw | bash

Or you can follow the steps discussed further below and setup everything manually.

Setting through Cloud Console

Follow the below steps to setup things using the Cloud Console.

1. Create the main service account (sa-2-high), and give it Project Editor Access.
2. Create the helper service account (sa-1-low), and don’t give any permissions to it initially.
3. Go to IAM — Service Accounts and select the service account (sa2-high).
4. Click on Show Info Panel. (on top right).
5. In the “Permissions” panel that opens up, click on “Add Member”.
6. In. the new member, write the email of sa-1-low service account.
7. For Role, Search and select “Service Account Token Creator”.
8. Click SAVE.
9. Now Select the service account (sa-1-low), Click on Actions — Create Key.

This is the only key you create, with no permissions on the projects.

Setting up through CLI

You can run the below set of commands on Cloud Shell, or on your local CLI.

Using The Short Lived credentials

Now that you have everything setup, and you have the near to harmless key file JSON present with you, let’s see how you can use this setup to interact with GCP. We will see options for your CLI commands and API calls.

Your CLI Scripts

Suppose You want to run the following CLI command:

gcloud iam service-accounts list

Step 1: Activate the credentials we just created

gcloud auth activate-service-account \
 --key-file my_harmless_key.json

Step 2: Use the impersonate option with all your CLI commands:

gcloud iam service-accounts list \
 --impersonate-service-account \
 sa-2-high@$GOOGLE_CLOUD_PROJECT.iam.gserviceaccount.com

You can add this impersonation flag with all your gcloud CLI commands, and can run these commands as if they are running using the credentials for sa-2-high, without these credentials existing at all !

API Calls in Scripts

We take example of a python script that makes an API call to one of the IAM APIs using temporary credentials:

Debating how is this approach safer

Let’s admit it, nothing is 100% safe, but all we can do with multiple approaches, is that we can narrow down the possibility of a compromise.

In an event the key called “my_harmless_key.json” gets exposed, all api calls made through this key shall fail as it has no permissions other than to impersonate credentials, and that too on only 1 specific service account.

In an event the malware/user tries to impersonate credentials, it would have no idea “which” service account to impersonate for, which is a required parameter.

The only and narrow chance to compromise is in an event that someone gets to access this key, and also is informed of “how to use it, i.e. which service account to impersonate it for”.

This situation is expected to happen generally in planned internal leaks, and less possible to happen in accidental leaks.

Can you detect the harmless accidental leak now leak

Yes. Since all automation scripts shall ideally use this credential for calling only one specific method, in an event that you observe that this credentials is being used to call other methods with errors, means this might have got compromised, and someone is trying to make a brute force attack.

The simple plan of action shall be to rotate this key. This monitoring process can even be automated.

Conclusion

We have successfully done the setup to obtain temporary credentials, and used then to run CLI commands and make API calls.

References

Google Cloud Official Documentation:

Creating short-lived service account credentials