Why AWS access and secret keys should not be in the codebase | Hacker News Reader

Why AWS access and secret keys should not be in the codebase

advancedweb.hu

11 pointssashee13 comments

Up next: Why you shouldn't shoot yourself in the face

True but it doesn’t help that most examples of “how to do $x in AWS” includes the secret key and access key in the constructor.

My credentials are still in the constructor, but are accessed through environment variables set in the CloudFormation file, like this:

  const client = new DocumentClient({
    region: process.env.REGION,
    accessKeyId: process.env.ACCESS_KEY_ID,
    secretAccessKey: process.env.SECRET_ACCESS_KEY
  });

Is this still a bad practice?

Yes, because now your credentials are in a cloud formation file that is still in source control.

You don’t need your credentials anywhere near your code.

Every AWS SDK that I’m aware of, let’s you new up your client with no parameters.

Your credentials should be in your user directory set by “aws configure” locally. When running on AWS, the SDK will automatically get your credentials based on the role attached to your EC2 instance or lambda.

Well, it does mean I don't need any kind of privileged access to your container, just 'ps -auwwe' as any user.

If you are on the EC2 instance where you can do ps, you can already access the secret key and access key by just doing:

  curl http://169.254.169.254/latest/meta-data/iam/security-credentials

But of course, you still shouldn't specify them in your code.

This might sound very obvious, and it is, but there are so many horror stories of people being charged tens of thousands of dollars because they accidentally pushed their secret keys to GitHub or any other public repository hubs, which are being scanned constantly for such credentials.

GitHub, for one, tries to stop them from being published by doing some scanning as well:

https://help.github.com/en/articles/about-token-scanning

Rails style encrypted credentials needs to be way more common! For python people there's https://pypi.org/project/django-encrypted-secrets/

That’s not the point. The point of the article is that you don’t need to manage AWS secret keys and access keys in your code at all.

When you’re developing locally they should be in your user directory and configured via the CLI (far away from your git repo) and when running on AWS, you should be using the attached profile. Either way, when you new up the client, the SDK will find them automatically.

Well, obviously! Actually...

A coworker pushed my passport details to a (private) github repository. Still freaking out about it, considering there's some sort of garbage collection, which keeps deleted items around for an undefined amount of time :|

If you haven’t yet, you can contact Github support to ask for help with scrubbing accidentally pushed secrets. They’re responsive, and while there’s no substitute for not having pushed it in the first place, it’s better than nothing.

Does rewriting git history to remove any trace of the secret not completely wipe it out from GH’s end? I know of a few secret-scrubbing tools that aid in this process.

Reply on news.ycombinator.com