AWS federation comes to GitHub Actions | Hacker News Reader

AWS federation comes to GitHub Actions

awsteele.com

121 pointsarkadiyt26 comments

Nice write up! By pure coincidence I asked GitHub for this feature 2 weeks ago [1] and they confirmed it was in the works.

[1]. https://twitter.com/micahhausler/status/1431350884810821637

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].

[1] https://mobile.twitter.com/__steele/status/14379684517173944...

I just mean that it was a coincidence that I asked GitHub for the feature and they were already working on it

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).

GCP does allow you to sign into a service account using OIDC credentials. Docs: https://cloud.google.com/iam/docs/access-resources-oidc

Shoutouts to Aidan, he always manages to dig up some real obscure AWS insights!

I can recommend checking out his trackiam project too: https://github.com/glassechidna/trackiam

This is amazing.

On a side note, are similar things (Assume an IAM role with federation instead of keys) possible at other platforms? Azure Devops perhaps?

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

https://aws.amazon.com/blogs/opensource/introducing-fine-gra...

Bitbucket has supported this for a while as well

Would it be posible to do it using Gitlab-CI?

I believe it should be - though I've not done it myself. One example I found was https://dev.to/stack-labs/securing-access-to-aws-iam-roles-f....

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.

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.

This can be done using KIAM for EKS runners, or if you are doing docker runners, you can use the "GitLab HA Scaling Runner Vending Machine for AWS EC2 ASG" here: https://gitlab.com/guided-explorations/aws/gitlab-runner-aut...

That last automation is designed to be self-service and can be setup in AWS Service Manager for teams to self-deploy their runners.

The many other benefits to the "GitLab HA Scaling Runner Vending Machine for AWS EC2 ASG" automation are enumerated here: https://gitlab.com/guided-explorations/aws/gitlab-runner-aut...

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.

[1]: https://docs.github.com/en/actions/reference/authentication-...

Yes a malicious fork will NOT be able to get a JWT just like they are not able to get any other secrets or privledges to the repo.

I was going to ask for a source, but I saw you've commented in the past that you're the GitHub Actions product manager.

This looks like a great feature to help keep long-lived AWS secrets out of my builds entirely.

Can HashiCorp vault do something similar, so you don't have to pass a vault token as a secret to your workflow?

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.

Slightly off-topic and a shameless plug but...

If you use Jenkins but want to play with GitHub Actions, my library allows that, plus some other cool things. https://github.com/DontShaveTheYak/jenkins-std-lib

Bitbucket also supports this:

https://support.atlassian.com/bitbucket-cloud/docs/deploy-on...

Do you know if there's anything similar in GitLab?

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...

Nice! This is exactly what I was looking for!

Reply on news.ycombinator.com