1. 10
  1. 5

    aws kms create-key

    I think that costs a little bit of money? IIRC I saw a dollar or so from KMS on my bill… Damn Bezos :D

    Anyway, fetching from a service that always reveals the secrets to your machine is not that different from a local file on that machine. It’s good against random people trying disk recovery on a volume (though that’s not a problem on EC2, they do wipe all data) and accidental backups/snapshots (“your VM is cast into an AMI” as you mentioned), but fundamentally it’s still secrets-on-your-machine.

    I think it might be reasonable for these services to support additional protection — not just based on secrets, but also, say, IP address whitelisting. So that if someone gets your secrets from an AMI you accidentally included secrets into and made public, they couldn’t access your accounts because they’re not accessing from your machines.

    1. 4


      costs $1/month until you delete it.


      1. 1

        costs a little bit of money

        Unfortunately, yes. As said below, it’s $1/mo. It’s unfortunate they charge for it, but most of the AWS accounts I’m privvy to are spending a couple hundred a month so it goes unnoticed.

        but also, say, IP address whitelisting

        Absolutely! I use an IAM instance role to allow retrieving and decrypting credentials, so the machine/container has to be launched in AWS and under the right role to allow retrieving credentials.

        With clouds being so dynamic, IP address whitelisting is harder – containers and instances come online at different places by default. Elastic IPs, etc, make some room for lockdown. Fetching secrets at container start, process start, etc is a great way to keep the secrets off the file system, but it’s only one component of the broader picture of protecting your database credentials.

        1. 2

          to allow retrieving credentials

          I mean, require the right IP/machine to connect to the service the credential is for. I guess you already have that for AWS services :)

      2. 3

        Rails’ credentials/secrets file is the devil. So I recently integrated envkey.com with my app, and it was a breeze to do. Might be a pricier than the AWS solution, but the capabilities I get are pretty nice.

        Being a super small startup, I preferred paying EnvKey some money to offload the dev effort to come up with something which would never be as good as the EnvKey solution.

        A few months in, and so far so good!

        1. 2

          Envkey.com looks interesting, and there’s definitely some merit to using a third party to store and encrypt your credentials over using aws to encrypt credentials for aws services.

          $20/month isn’t terrible, but it’s a bit pricey and per-seat pricing feels a little out of line with the value of the service they’re providing. But who am I to judge a SaaS that looks like it’s paying the rent?

          I worry about one thing: how do you securely deploy your envkey api key?

          This is the same problem with HashiCorp Vault or any external secret keeper. There’s a secret which unlocks all your other secrets…that makes it the most important secret. How are you injecting that secret into your application? The whole reason the AWS Parameter store is viable is that access to download and decrypt your secrets isn’t controlled by a key stored on the machine. It’s controlled by the EC2 or container’s instance role.

          1. 2

            Hashicorp Vault has many ways to authenticate and get a token, you can tie to EC2, or you can auth against LDAP/Github, AppRole(where you can tie it to specific machine(s)/applications, etc. But it is definitely a turtles all the way down approach. The goal of Vault is to only have to worry about deploying the token and vault will then handle ALL of your secret/sensitive information for you, with transit, DB and the other backends. So at least the problem becomes “manageable” since it’s only the 1 token you have to get out there.