
Why AWS access and secret keys should not be in the codebase - sashee
https://advancedweb.hu/2019/05/28/aws_config_credentials/
======
nprateem
Up next: Why you shouldn't shoot yourself in the face

~~~
scarface74
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.

~~~
SwiftyBug
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?

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

~~~
scarface74
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.

------
hmd_imputer
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.

~~~
mcbain
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](https://help.github.com/en/articles/about-token-scanning)

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

~~~
scarface74
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.

------
sk0g
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 :|

~~~
fcarraldo
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.

~~~
applecrazy
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.

