[HN Gopher] Show HN: Stop Putting AWS Credentials in GitHub Secrets
___________________________________________________________________
Show HN: Stop Putting AWS Credentials in GitHub Secrets
Greetings! I've created a GitHub action that works that allows
GitHub Actions to exchange a GitHub token for AWS Access
Credentials. I've cultivated a few examples of it in action:
https://github.com/saml-to/aws-assume-role-action-examples I've
always found management of AWS Credentials has been a pain. So this
setting up this Action works like this: 1) A SAML Identity
Provider is created in AWS 2) A Role in AWS is set up to trust
that Identity Provider 3) A config file is added to the repository
indicating which role can be assumed 4) The GitHub Action
exchanges the Repo Secret for AWS Credentials using the SAML.to
backend for the exchange Let me know what you think! I'm Happy to
take questions and comments here or on Gitter:
https://gitter.im/saml-to/assume-aws-role-action
Author : cnuss
Score : 36 points
Date : 2022-01-18 19:50 UTC (3 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| mdaniel wrote:
| Some observations:
|
| * it seems your package.json is still from an old iteration:
| https://github.com/saml-to/assume-aws-role-action/blob/main/...
|
| * it was super opaque where this relative import comes from:
| https://github.com/saml-to/assume-aws-role-action/blob/main/...
| but after some sniffing around, it seems to be some openapi
| generation magick https://github.com/saml-to/assume-aws-role-
| action/blob/main/... against one of your own API endpoints
| https://github.com/saml-to/assume-aws-role-action/blob/main/...
| which seems to mean that using this toy is not "self contained"
| in the way that `sts:AssumeRoleWithWebIdentity` is
| cnuss wrote:
| Thanks mdaniel for your observations!
|
| I updated package.json!
|
| On the note of the API endpoint. Yes that's correct, I've
| fashioned a backend API which handles converting of GitHub Repo
| Tokens to SAML Assertions:
| https://sso.saml.to/github/swagger.html#/IDP/AssumeRoleForRe...
|
| And providing a static endpoint for SAML Metadata:
| https://saml.to/metadata
|
| That being said, you're making my brain click a little bit and
| this could be converted into a "self contained" toy, with some
| additional work! The biggest piece of the puzzle is a
| consistent private key and certificate.
|
| If that is of interest to you, could you create a GitHub Issue
| as a feature request?
|
| Thanks!
| SahAssar wrote:
| The title "Show HN: Stop Putting AWS Credentials in GitHub
| Secrets" to me sounds like it's exposing some sort of specific
| vulunerability or similar but I might just be overreacting
| because of all the recent hacks.
|
| A title like "Show HN: A GitHub action to help using AWS
| credentials" sounds more appropriate to me, saying what it is and
| what it does instead of saying what not to do.
| cnuss wrote:
| Thanks for the feedback SahAssar, sorry if the title caused any
| latent anxiety!
|
| I'll heed your advice for the next time I post something on HN,
| thank you!
| SahAssar wrote:
| No problem, it was more like morbid curiosity.
|
| Writing titles that are direct enough for HN but still
| enthusiastic and marketable can be hard. I can't find the
| comment right now, but someone said a good rule is to start
| with "what it is" then "what it does" and last "why you think
| it's good"
| zricethezav wrote:
| Speaking of credentials, you can use
| https://github.com/zricethezav/gitleaks to check if your repos
| contain any secrets
| cnuss wrote:
| This is awesome! thank you!
| zomglings wrote:
| What is wrong with putting AWS credentials in GitHub secrets?
| cnuss wrote:
| Hey zomglings!
|
| I'll echo what I just responded to nodesocket with, but I'd
| also love your feedback on my comment:
|
| https://news.ycombinator.com/item?id=29986209
| sitharus wrote:
| Nothing in general, there's just a new and more secure way of
| doing things. There's no reason to change if you're comfortable
| with the existing way of doing things.
|
| Personally I trust GitHub to get the security right more often
| than I will.
| jackson1442 wrote:
| So I've personally started using this:
| https://docs.github.com/en/actions/deployment/security-harde...
|
| (which appears to be rather similar to saml-to, just with OIDC
| instead of saml.) The reason being that we try to avoid
| creating long-lived credentials at all where I work. Everyone
| uses SSO to sign into AWS with a provisioned IAM role, no one
| has an IAM user, etc. This means there just _aren't_
| credentials floating out there, SSO sessions last 12 hours, and
| Github gets an OIDC token when it needs one.
|
| This means there are no credentials to leak (for the most part-
| there are some edge cases that necessitate creating an access
| key), they generally are harder to mix up (each aws account is
| for a separate business purpose, so there are lots of them),
| and CloudTrail lists _who_ did every action since SSO adds your
| email to your IAM identity and devs don't have long-lived
| service credentials.
|
| In short, there's nothing _wrong_ with using Secrets to store
| your tokens, but it's useful in some cases for cohesion. If
| you're already handing out long-lived tokens to devs or other
| services, there's not really any reason to stop doing that with
| github.
| orf wrote:
| Isn't it just this? https://awsteele.com/blog/2021/09/15/aws-
| federation-comes-to...
| (https://github.com/github/roadmap/issues/249)
|
| Why does SAML.to need to be used?
| cnuss wrote:
| Hey orf!
|
| You are correct this GitHub action is at its core is very
| similar! Even though the initial instructions don't prescribe
| it, the biggest differentiator is that SAML.to supports a
| centralized permissions configuration across all repositories
| for a user, project or organization:
|
| https://github.com/saml-to/assume-aws-role-action/blob/main/...
|
| Also, this action is the tip of the iceberg of what SAML.to
| aims to provide (check out https://saml.to), for example:
|
| - Store Role Assumption and Privileges as Code (the saml-to.yml
| config file) - A command line interface to login and assume
| roles - Free (or affordable) for small teams or individuals -
| Additional Automations, Webhooks, SCIM, etc
|
| Let me know if you have any comments on this and thanks for the
| question!
| johnnypangs wrote:
| Does anyone know the differences between saml and open id
| connect? https://docs.github.com/en/enterprise-
| cloud@latest/actions/d...
| cnuss wrote:
| They're both Identity Protocols, SAML is older and more widely
| adopted, OIDC is newer. Kinda the XML vs JSON battle at a
| Protocol level haha!
|
| I've found a lot of SaaS providers only support SAML today, so
| you're stuck if you want to use GitHub identity outside of
| OIDC.
| nodesocket wrote:
| Complexity, the enemy of security. Why is using GitHub secrets
| insecure exactly?
| hacker_newz wrote:
| Why does a third party need access to your AWS credentials?
| VectorLock wrote:
| To do stuff in your AWS account.
| nodesocket wrote:
| One of many reasons is pushing containers from GitHub Actions
| automation to AWS ECR (registry).
| cnuss wrote:
| Totally agree re: complexity. My goal is that a few config
| steps in a GitHub repository and AWS makes a GitHub action able
| to do a wide variety of things (such as accessing multiple
| accounts) with very little upstart work.
|
| Storing Secrets in GitHub isn't technically insecure, and it's
| awesome it's provided as a free feature, but it's tedious and
| fragile. Someone (or something has to do various clicks and
| copy/pastes or API calls) to upload an access key into GitHub
| Secrets. It gets even worse if you have multiple accounts and
| then your Action Workflow file gets really gnarly if you simply
| pull credentials from ${{ secrets.* }}.
|
| Also, if you need to rotate your AWS access tokens, you open up
| a whole new can of worms, so why not remove credentials all
| together!
|
| Thanks for the question nodesocket, let me know if you have
| more questions or comments!
___________________________________________________________________
(page generated 2022-01-18 23:01 UTC)