I would not say a pure coincidence. Whilst Aidan has been hanging out for this for quite a while, he was tipped off as to the imminence of the feature by GitHub's response in your thread[1].
This is a great news, fewer places that I have to create secret keys. I know this is a AWS blog post, but wish I can do similar thing with GCP (of course from GH).
On Gitlab CI if you run your runners in kubernetes you can assume a Kubernetes Service Account which then will get you access through the same mechanism
There are a couple approaches. GitLab's JWT token allows custom scripting to interface it to other systems. This demo shows custom integration with Vault (it also demonstrates our native integration - so you have to parse out which code you are looking at): https://gitlab.com/bdowney/vault-demo
Another approach is placing a GitLab runner within AWS and assigning it an IAM role directly. While this isn't as flexible, it is also not as complex to debug why a specific user can't build or deploy a job when another can.
In this scheme, there is potentially a runner per-dev team that has the same exact IAM profile as the dev team.
In addition, you can just assign IAM roles to the runner EC2 instances themselves, placing ALL of the authentication and authorization in AWS rather than in GitLab. Then the runner will only be able to access the things that you allow through its IAM policy.
Nice. We implemented something similar using a custom GitHub App & a Lambda running on AWS calling STS AssumeRole. That has the added benefit of being able to restrict the permissions further using an inline policy, so that different repositories get different permissions (but is much more tedious to implement than this :).
This is great. I can see tons of use for this in any shop which deploys to AWS and uses github actions, rather than a more complicated CI/CD process (like code deploy haha).
I'm interested in his teaser comment at the end; here's more about role session tags: https://docs.aws.amazon.com/IAM/latest/UserGuide/id_session-... So it is looking like he might want to extract some values from the github provided JWT and use that to request more narrowly defined permissions?
Finally, I'm surprised no "JWT is awful and insecure" folks have posted yet, though.
Good stuff. IAM roles for deployment tend to be quite broad in my experience, and rarely rotated. GitHub Actions generally does a solid job of protecting their Secrets service from being logged or accessed inappropriately, but it isn’t bulletproof against internal access or malicious actions. OIDC can be intimidating to set up so this tutorial is quite welcome.
Note that some Actions run with lower permission and cannot access GitHub Secrets. For example, actions triggered by Dependabot PRs cannot access secrets. This would normally prevent untrusted updates from testing/deploying on your AWS Account. Maybe federation would bypass these protections that depend on the identity triggering the action.
There's a lack of documentation since this isn't officially released yet, but my assumption is that you need write permissions to id-token in order to generate a JWT. As forked repos can at most get read access[1], presumably that would prevent a malicious fork job from generating the JWT.
I would imagine you could do the same with it, given that it supports OIDC Auth, where GitHub acts as an OIDC Identity Provider. You just have to set up the mappings.
There's an open issue to try to enable it - Gitlab issues a unique JWT to every pipeline but it's not directly consumable by AWS right now so you'd have to write an intermediate service that could convert the gitlab token into an AWS session: https://gitlab.com/gitlab-org/gitlab/-/issues/216259#note_44...
[1]. https://twitter.com/micahhausler/status/1431350884810821637