Use Google Cloud user credentials when testing containers locally

Container packaging is very popular today: it allows a full customization of the execution environment and is language agnostic. More and more applications use it.
So now, to validate the production environment behavior, the developers need to test the containers, not only the workload with unit tests.

In some cases, the containerized app can required to access to Google Cloud API and thus, to be authenticated. When deployed on Google Cloud services, metadata server is reachable and provides the Application Default Credentials (ADC).

How to get authenticated locally with ADC for testing?

By definition, the container run in an isolated environment. That means that your local configuration isn’t known from inside the container, and thus your credentials aren’t loaded

Service account key file solution

If you go on Google search with this query google cloud container test authentication, the first link leads you to Cloud Run local test tutorial.
It’s a great tutorial which explains how to load credentials in the container runtime environment for local tests.

But the suggested JSON file to use is a service account key file. It must be generated and stored locally!

This solution isn’t safe enough and, as described in my previous article, I would like to avoid service account key files. Furthermore, it’s a great question of Eran Chetzroni which has inspired this article.

Local environment and user credentials

When you code your app on your local environment, you use Google auth libraries according with your prefered languages. This library can be used directly in your code, or it can be used as dependency in service specific libraries, such as Cloud Storage client library.

The Google auth library tries to get a valid credentials by performing checks in this order

• Look at the environment variable GOOGLE_APPLICATION_CREDENTIALS value. If exists, use it, else…
• Look at the metadata server (only on Google Cloud Platform). If it returns correct HTTP codes, use it, else…
• Look at “well-know” location if a user credential JSON file exists

The “well-known” locations are

• On linux: ~/.config/gcloud/application_default_credentials.json
• On Windows: %appdata%/gcloud/application_default_credentials.json

To get your default user credentials on your local environment, you have to use the gcloud SDK. You have 2 commands to get authentication:

• gcloud auth login to get authenticated on all subsequent gcloud commands
• gcloud auth application-default login to create your ADC locally, in a “well-known” location.

Both commands trigger an OAuth2 authentication flow, synchronous or asynchronous, and store a refresh token locally.

Load your user credentials in your container

Now, we have the 2 pieces of the puzzle

• The JSON credential file. Of course, not a Service Account credential and thus the 2 IAM limits apply here
• The command to load a JSON credential when you run a container. I won’t reinvent the wheel, the Cloud Run tutorial solution is great!

Therefore, you have to run your local docker run command like this

ADC=~/.config/gcloud/application_default_credentials.json \
docker run \
<YOUR PARAMS> \
-e GOOGLE_APPLICATION_CREDENTIALS=/tmp/keys/FILE_NAME.json \
-v ${ADC}:/tmp/keys/FILE_NAME.json:ro \
<IMAGE_URL>

Avoid service account key file

Here again, an easy solution exists to prevent the use of service account key files on a local environment.

However, even if this solution is great, don’t be too inspired for using it outside of your local environment. The JSON files, your user credentials JSON file or the service account key file, are “secrets” and need to be handled as secrets.

Thus, never add these JSON files into your container, especially if it’s public. A container is simply a packaging mode, it encrypts/hides nothing!

Don’t use your user credentials in another environment than your local and your own environment (such as production, staging,…). The API access will be perform on your behalf (and logged as-is), with your authorizations.
And, because it’s a user credential, you can be blocked by the 2 IAM limits.

So, as always, when playing with security, think wisely!