6 points by abhijais1 21 hours ago
Hey I have been working on a solution to prevent secrets from committing to VCS repos, so far have prevented 10+ AWS keys from accidentally being committed. Github has an offering but it's very costly for our team. Does anyone of you want to try out ?
perplexity offered me those:
https://github.com/awslabs/git-secrets
https://www.infracloud.io/blogs/prevent-secret-leaks-in-repo...
https://www.reddit.com/r/git/comments/1h1r0ep/best_practices...
In addition GitGuardian cost something around $220/year per developer which is not too bad
Why are AWS keys anywhere near your code in the first place?
For instance in Python, you initialize an object using
boto3.client(“s3”)
Even if you use “aws configure” and have long lasting keys (don’t do that), your keys will be stored in your home directory, nowhere near your repository and still usable locally.
When running your code on AWS, whatever you are using to run it on will get permission from the IAM role attached to the Lambda, EC2, etc.
It tends to happen more on front end I think, especially since it's in the tutorial and many haven't been given the training on what to do better. Not really AWS, but even the trained ones will put it in a .local.properties file or something and then forget to add it to gitignore
There is no sample code from AWS that has you read access keys in your code from a .local file. The SDK automatically picks it up from your local environment when you run AWS configure to store them in your home directory or better when you get temporary credentials via the IAM identity center and store them in environment variables
You really just need to not forget to do that. Isn’t it that simple?
A less snarky answer, and why AWS is largely a non issue these days is because the secrets were designed out of code And are effectively provided as an integral part of the infrastructure which includes regular and reliable expiration and rotation. So any chance you get, design secrets in this way.
The only thing ever in code are references to the correct roles or secrets. Only ever references to the location of the secret. Get in the habit of this and the problem is drastically reduced and becomes something you don’t have to think about.
In a ideal world yes developers should care about these issues but developers need access to AWS keys to locally test integration with AWS services like SQS and Dynamo so access to micro service keys needs to be provided.
The problem occurs when they forget and commit, that key needs to be rotated which has caused downtimes in the past, or scrubbed which involves a messy fight with VCS support teams.
The problem is not just AWS, in general for third party integrations with platform like banks developers needs to test locally but they forget removing those keys. Each keys committed is a potential SOC2 / PCI non-compliance avenue.
You never need to have your access keys in your repository or read them explicitly from any properties file. The SDK will automatically get the keys from your home directory when you run your code.
The easy but less secure solution:
Store all secrets in one file WITHIN your local repo and add that one secrets file to something like a .gitignore file. Then validate the file is excluded using git status.
The more secure solution is to store all secrets within a secrets vault and access that vault from application logic on application restart, provided the application is a service that rarely restarts.