3 ms·

What is wrong with putting AWS credentials in GitHub secrets?

sitharus 5y ago
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.
cnuss 5y ago
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 https://news.ycombinator.com/item?id=29986209
jackson1442 5y ago
So I've personally started using this: https://docs.github.com/en/actions/deployment/security-hardening-your-deployments/about-security-hardening-with-openid-connect#configuring-the-oidc-trust-with-the-cloud 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.
NovemberWhiskey 5y ago
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?
0xbadcafebee 5y ago
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.

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.

cnuss 5y ago

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 https://news.ycombinator.com/item?id=29986209

jackson1442 5y ago

So I've personally started using this: https://docs.github.com/en/actions/deployment/security-hardening-your-deployments/about-security-hardening-with-openid-connect#configuring-the-oidc-trust-with-the-cloud 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.

NovemberWhiskey 5y ago

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?

0xbadcafebee 5y ago

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.