HN Explorer

27 comments

[ 3.8 ms ] story [ 72.9 ms ] thread
captn3m0
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?

sitharus
Bitbucket has supported this for a while as well
zeneke
Would it be posible to do it using Gitlab-CI?
boleary-gl
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.

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

a012
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).
henriks
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 :).
joshuanapoli
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.
Deathmax
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-...

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

stoobs
Nice! This is exactly what I was looking for!
candiddevmike
Can HashiCorp vault do something similar, so you don't have to pass a vault token as a secret to your workflow?
vegardx
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.
mooreds
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.

micah_chatt
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

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