By guillaume blaquiere．Apr 3, 2020
Security is a great challenge for cloud providers and Google Cloud Platform has chosen to secure all its services with OAuth2 protocol. The security token is passed in the header of the API calls for identifing the user. The authorizations are based on roles and they are checked in IAM.
This token can identify an user account, but also a service account. In machine-to-machine call, it’s this type of authentification which is used.
Generate an Id Token with gcloud command
When you try to reach services, like private Cloud Run or private Cloud Functions, a signed id token is required. This token can be easily generated with gcloud SDK with your user account
# Authenticate with your service account
gcloud auth login # Generate an id token
gcloud auth print-identity-token
Or with a service account key file
# Load the service account identity
gcloud auth activate-service-account --key-file=key.json# Generate an id token
gcloud auth print-identity-token
A special trick, you can impersonate a service account and use it like this
# Generate an id token
gcloud auth print-identity-token \
SA with the service account name and
PROJECT_ID by your project ID
Generate an Id Token on Google Cloud environment
On GCP, each component has its own identity, this mean that a service account is automatically attached to the component. This service account is customizable for a better right segregation and for applying the least privilege principle on each component.
If no service account are specified, this one per default is used, often the compute default service account with this pattern:
Thereby, you don’t need to generate a service account key file for using a specific service account. You can directly use the component identity through the metadata server. Here an example in Cloud Run
Note: When you are on GCP environment, I strongly recommend to never use service account key files. They are
- Useless thanks to component identity
- Hard to secure (or store them in secret manager)
- Hard to track
- Hard to rotate regularly (recommended every 90 days)
Generate an Id Token from outside GCP
However, when you aren’t on GCP and you want to generate a id_token with an automatic platform (I mean without a user account), you must have a service account key file.
This happen in several cases:
- You have to interact with GCP services in a CI/CD platform
- You have an application hosted outside GCP (on premise or on other cloud provider)
- Developers don’t have a Google account that you can grant in IAM
When developers aren’t familiar with GCP or if they use old framework, it can be hard to generate an id token. I recently coped with 2 use cases:
- Developers want to use Postman for testing a Cloud Run private API. without gcloud installed. They had difficulties to set up an easy process for their tests
- .Net 4.0 framework is used, and some handful methods for building a JWT token are missing and they have to be implemented manually.
This last case can occur with any old language and/or framework. In application modernisation it can be challenging and a blocker.
Token-generator for generating id token
For helping the developers and for preventing any project delay, I implemented a small tool, token-generator, which generate id_token based on a service account key file provided in parameter.
This tool exposes a web-server accessible on localhost. The idea is to simply perform a
GET query on this server for getting a valid token ID.
- Developers launch token-generator on their local environment and simply perform a get on localhost and use the result in the authorization header as Bearer token.
- Old applications/frameworks launch token-generator as a side program on a free port on the server, and perform a simple GET in localhost for getting the token and use it in subsequent queries
Use Token-generator anywhere…
I open sourced this small and useful tool on GitHub. It is written in Go and can be compiled for several platform (today 3 are automatically generated on each released).
Because of Go, the process is light, efficient and has no impact on the performance. You can use as you want when you have a blocking point for generating id token.
… and with caution
But this tool doesn’t prevent misuse of service account key file, especially the storage in SCM tools like Git.
In addition, you absolutely mustn’t expose this service publicly on internet. It’s designed for running locally, in collocation with other software.
I will be happy to have feedback and to discuss about your use cases that lead you to use, or not, this tool. You can also open issues on GitHub.
The original article published on Medium.