How Open ID Join works (illustrated)
I first realized about Open ID Join (OIDC) whereas engaged on digger, an IaC automation software. The primary part of Digger is a cli which integrates immediately in your CI system of selection.
The primary time we approached implementing oidc we have been lazy and determined to leverage the github motion setup-aws which does it for us below the hood. Then later we had some further necessities which meant that OIDC wanted to be carried out as part of digger which meant that I wanted to grasp how OIDC works on a deeper degree. Going via the official draft of OIDC to me was much like studying an official spec for OAuth – too many summary phrases that make it obscure. By way of some trial and error in addition to counting on github’s docs for implementing OIDC, and reverse engineering the setup-aws typescript code I bought a working version for OIDC inside digger utilizing the aws sdk.
Over right here I wish to clarify my learnings in a simplified means in order that you can also perceive how all this voodoo magic works below the hood. This text will deal with AWS companies, however it works very equally in different cloud suppliers as nicely.
It began with keys:
Historically the best strategy to authenticate on AWS was through keys. you created a pair of keys and used these to authenticate in your software code and in your CI techniques to no matter companies you wanted. This was the only strategy to authenticate and entry the cloud companies.
lengthy lived keys aren’t safe
From a safety perspective, long-lived passwords, tokens and keys aren’t safe to be saved. As a substitute it is best to depend on rotating keys periodically and ideally by no means storing them. That is the place the function of AWS roles got here helpful. Now inside EC2, lambda, codebuild and different companies the place your code ran you have been capable of assume a task and entry different aws cloud companies. Really, below the hood the proccess of “assuming a task” generates a short lived set of AWS key, AWS secret and a session token for accessing these companies. These keys are legitimate for an hour and may be set to run out sooner. Now as a developer you not wanted to retailer any keys in your software code or fear about having them as secrets and techniques or rotating them, nice!
How do I entry my AWS from the skin world?
However, how can we acquire keyless entry from outdoors AWS, for instance in my github actions CI system? Do I would like to make use of AWS keys and hardcode them in my secrets and techniques retailer, then manually rotate them periodically?
That is the place OIDC comes into play. At first it looks as if blackmagic the way it works. attributable to how a lot of the move is abstracted away from the consumer. The steps to make use of OIDC with AWS+github actions are as follows:
- Create a task on AWS, add belief coverage specifying which github org+repo are allowed to entry this AWS function
- Create an identification supplier for github actions
- use the setup-aws motion, specify the function and it’ll handle the remaining
Alot is hidden away from the way it works, and also you would possibly guess there may be some key change happening between AWS and github or one thing like that. Really its a lot easier in the event you have a look at the way it actually works. Should you needed to implement OIDC with out counting on some other code that is how you’d do it:
- Github spins up an Motion together with your pipeline code
- Each motion job comes with a token as an envirionment variable for authenticated calls to github
- You ship a publish request to github, asking for a “internet identification token“
- You ship this token to AWS, exchanging it for (you visitor it) a pair of keys and session token
- You employ this set of keys to authenticate with AWS companies as regular
The important thing level right here is that the “internet identification token” is a JWT token signed by github and who’s contents may be verified by AWS utilizing github’s public key. Due to this fact AWS can confirm the important thing and use the information inside the JWT token to confirm entry solely utilizing the token alone. For the reason that token additionally incorporates “scopes” corresponding to organisation, repo, department, AWS can both grant or deny entry primarily based on these scopes inside the verified JWT token.
So there you might have it, an illustrated information to OIDC with AWS and Github actions. Different CIs and cloud suppliers additionally work in an analogous means.