This article is written by Rik Pauwels, Senior Data Architect at Devoteam G Cloud Benelux
The challenge:
Safely rotating, distributing and storing keys is stressful to say the least so my colleagues and I were very pleased to hear that GitHub Actions, the CI/CD platform of GitHub, recently made it possible to perform keyless authentication with openid connect (OIDC). This article covers both the working of OIDC as well as example code to play with it yourself.
Using OpenID Connect to harden your security
OpenID Connect, or OIDC in short, is an authentication extension on top of the well known OAuth 2.0 authorization standard. Where OAuth 2.0 ensures that you can do what you may do, OIDC will make sure that you are who you say you are.
The need of OIDC explained with an example
These terms can sound confusing so here is a little example; Let’s say you have a bakery and a database on Google Cloud with a list of cakes, their ingredients and the stock. You are very busy so you hired an automatic supplier that periodically checks your database to see if you have enough stock. To do so you have given this supplier a key with the permissions to view your data. Now the supplier can, using the OAuth 2.0 protocol, access the inventory data and everybody is happy.
Without you knowing your supplier has written your key onto his whiteboard in his shop to help him remember the value. Now one day, one of your competitors comes into the suppliers office and sees the key and this is where things might get ugly. OAuth 2.0 flow does not check who is using the key so your competitor can also use the key and steal all your recipes. To make things worse, you don’t even know that somebody other than your supplier has access to your database until you suddenly see your cakes being sold in another bakery!
This might seem like a far-fetched example but you will be surprised how much keys are still shared in plain text via email or stored in public accessible documents just because it is easy for the user.
How to set up OIDC to enhance your security
OIDC solves both the identity problem (who is trying to access my data) and the key storage problem by generating short lived tokens for only the people that you trust. These short lived keys are regenerated each time the client tries to read the data so storing them is pointless. This directly eliminates the need for secure, long term storage.
Checking the identity of the caller in the OIDC protocol is done via an OIDC capable Identity Provider (IdP) you trust. This IdP will generate a JSON Web Token (JWT) which contains data about your identity together with a cryptographic signature so other parties can check the validity of the token.
The receiving end, in our case Google’s security token service (STS), can then check the token and determine if that person may have access to the data. If so, it will receive a temporary token which can be used in the next session for a limited amount of time.
Since no keys need to be manually exchanged nor stored you don’t have to worry anymore about malicious users stealing your long living keys.
Configuring who gets access to your GCP environment
In the Google Cloud ecosystem the usage of multiple identities of multiple identity providers is called workload identity federation. To enable it you have to create a workload identity pool. This pool contains all the identity providers you trust and will be checked each time a person tries to get a short lived access token by the Google STS. The final piece of the puzzle is giving the workload identity pool access to impersonate one or more Google Cloud service accounts with the correct permissions to get the job done.
We fully recommend everybody to check the following repository for examples and terraform code to set this up in no-time: https://github.com/terraform-google-modules/terraform-google-github-actions-runners/tree/master/modules/gh-oidc
Happy experimenting and may no one ever have to worry about key rotations again! Are you not really fond of experimenting yourselves or do you still have questions on using OpenID Connect? Then don’t hesitate to reach out to our security experts.
Interesting resources
- Github actions documentation:
- Google blogs: