Show HN: Stop Putting AWS Credentials in GitHub Secrets(github.com)
github.com
Show HN: Stop Putting AWS Credentials in GitHub Secrets
https://github.com/saml-to/assume-aws-role-action
30 comments
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.
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.
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!
I'll heed your advice for the next time I post something on HN, thank you!
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"
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"
This, all of this. I was thinking it was a vuln too, but it's no big deal. At this point the Internet has made us sort of desensitized to clickbait, even accidental ones :]
Anyway neat idea!
Anyway neat idea!
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?
Why does SAML.to need to be used?
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!
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!
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
* 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
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!
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!
I remember receiving a bill for 5K from Amazon once. When inspecting I realized that someone had found my keys in a public GitHub repo I had and was using my account to mine bitcoins. Thankfully AWS support was understanding and forgave me that amount.
Other than never exposing keys like that I learned to never hide admin keys and to always create roles specific to the use case. It doesn’t fully protect you but at least it prevents abuse on your behalf.
Other than never exposing keys like that I learned to never hide admin keys and to always create roles specific to the use case. It doesn’t fully protect you but at least it prevents abuse on your behalf.
Does anyone know the differences between saml and open id connect? https://docs.github.com/en/enterprise-cloud@latest/actions/d...
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.
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.
What is wrong with putting AWS credentials in GitHub secrets?
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.
(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.
A static AWS credential (otherwise known as "AWS Access Key ID & AWS Secret Key") can be leaked or stolen. The stolen AWS credentials can then be re-used again and again by whoever has them because they're not temporary.
A static credential is sometimes shared among many users, making it very difficult to audit their use.
When was the last time you changed the AWS credentials when somebody left a company? They probably still have the old credentials and they probably still work.
If your computer gets infected with malware, the malware can look for credentials on your system (not difficult to match on them with regular expressions searching through files).
Some people use their own user's personal static credentials for things like CI/CD, and their personal static credentials often have Admin access to the AWS account. This is a lot more access than should be given to some automation system.
A hacker can use them to spin up 100 giant EC2 instances in your AWS account to mine crypto / send spam / DDoS, and charge your AWS account $500,000 in a month.
A static credential is sometimes shared among many users, making it very difficult to audit their use.
When was the last time you changed the AWS credentials when somebody left a company? They probably still have the old credentials and they probably still work.
If your computer gets infected with malware, the malware can look for credentials on your system (not difficult to match on them with regular expressions searching through files).
Some people use their own user's personal static credentials for things like CI/CD, and their personal static credentials often have Admin access to the AWS account. This is a lot more access than should be given to some automation system.
A hacker can use them to spin up 100 giant EC2 instances in your AWS account to mine crypto / send spam / DDoS, and charge your AWS account $500,000 in a month.
I mean, it's much better than putting them in your source code, but why have a long-lived credential at all if you can avoid it?
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
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
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.
Personally I trust GitHub to get the security right more often than I will.
But then what would happen if the GitHub token leaks? Would someone then be able to retrieve their own credentials as if they were your CI/CD pipeline? I feel like it be hard to audit that because a baddie would then be able to blend in with your CI/CD pipeline's traffic.
But you say you find "management of AWS Credentials a pain", so I guess this isn't for security purposes, right? More of just a convenience?
Don't get me wrong, I'm all about lessening the amount of environment variables in a pipeline!.. especially with ones that you want to rotate!
But you say you find "management of AWS Credentials a pain", so I guess this isn't for security purposes, right? More of just a convenience?
Don't get me wrong, I'm all about lessening the amount of environment variables in a pipeline!.. especially with ones that you want to rotate!
The GitHub token that is used is a short-lived token that is generated new every time a GitHub action is run.
Ref: https://docs.github.com/en/actions/security-guides/automatic...
And the SAML.to backend first checks to make sure the token is valid by invoking:
Ref: https://docs.github.com/en/rest/reference/apps#list-reposito...
I haven't checked, but I assume GitHub invalidates the token when the GitHub Action finishes
Ref: https://docs.github.com/en/actions/security-guides/automatic...
And the SAML.to backend first checks to make sure the token is valid by invoking:
Ref: https://docs.github.com/en/rest/reference/apps#list-reposito...
I haven't checked, but I assume GitHub invalidates the token when the GitHub Action finishes
Complexity, the enemy of security. Why is using GitHub secrets insecure exactly?
Having IAM keys in your secrets isn't insecure.
However you now have long-lived keys.
They tend to get used across multiple projects, and despite the best practice being to rotate keys frequently, it's rarely done.
You also have no idea who has them, and without the use of, say, Cloudtrail, you don't know if anyone is using them (even Cloudtrail might not pick up on everything)
The approach here is to get short-lived keys, when they are needed.
However you now have long-lived keys.
They tend to get used across multiple projects, and despite the best practice being to rotate keys frequently, it's rarely done.
You also have no idea who has them, and without the use of, say, Cloudtrail, you don't know if anyone is using them (even Cloudtrail might not pick up on everything)
The approach here is to get short-lived keys, when they are needed.
Why does a third party need access to your AWS credentials?
One of many reasons is pushing containers from GitHub Actions automation to AWS ECR (registry).
To do stuff in your AWS account.
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!
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!
Speaking of credentials, you can use https://github.com/zricethezav/gitleaks to check if your repos contain any secrets
This is awesome! thank you!
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