Don't use ENV variables for secret data (2017)

>those credentials will then be in your projects history forever more (or until nuking the history becomes more important than keeping the history)

With Git, it's not "nuking" so much as "retroactively creating a different timeline in which the secret wasn't shared." Still a pain in the ass if there's more than one developer.

> If an application spawns a sub-process, that sub-process will inherit all environment variables.

...“by default”, specifying the environment is something you do when creating a new process.

Vault looks cool, but looking at the reference architecture [1] my guts tell me it's much easier to fuck up setting up a Vault cluster than environment variables.

[1] https://learn.hashicorp.com/vault/operations/ops-reference-a...

Are secrets specific to docker-swarm? If you're using plain docker, I imagine this wouldn't work?

k8s has its own secrets system built into deployments. I haven't used it though. I've been at shops that use k8s+vault, and other places that uses marathon/DCOS+consoul.

If you're on AWS you can use pod2iam in a k8s cluster and then use the SSM parameter store to encrypt/decrypt secrets based on pod roles. I'm sure Google Cloud must have similar services.

The most agnostic way would be to mount in a file or volume at runtime. It's still accessible to the process, but just via the filesystem and not via environment variables. You still need to program with security in mind, but it's less likely for inadvertent leaks; basic layers of security. From there you could use something that encrypts that mount at rest and decrypt it when you start the container.

> Environment variables are passed down to child processes, which allows for unintended access.

Doesn't this depend on how you create the new process? fork() would keep a copy of the env in both parent/child processes and exec would keep the env because it replaces the current process. But if you start a process using something like the subprocessing module in Python, it would give you a fresh shell for that process, right?

I came across a blogpost describing this workflow recently and I'm curious to hear HN opinions about it. Any pitfalls?

https://matthewdowney.github.io/encrypting-keys-in-clojure-a...

1. Generate a new set of API keys.

2. Read my encrypted map of keys from disk, decrypt it with a passphrase, assoc in the new key & secret, encrypt it again, and write it to disk.

3. At the entry point for my application, use (.readPassword (System/console)) to securely read in the passphrase, and then use it to decrypt the key file and read it into a Clojure map.

4. Instead of passing the key map around (allowing it to potentially escape into a debug log, or be printed at the REPL if I do something dumb), the top level code of my application passes the credentials into a signer-factory for each api that closes over the credentials.

    ;; The factory is shaped something like this
    (defn request-signer-factory 
      [{:keys [key secret]]
      (fn [request-to-sign]
        (sign-request request-to-sign key secret)))
       
    ;; Then an API endpoint looks like this
    (defn place-order! 
      [signer {:keys [price qty side market post-only?]}]
      (let [request (comment "Format the order data for the exchange")
            signed (singer request)]
        (do-http-request! signed)))

I like this workflow more than others which are centered around only encrypting credentials inside of your Git repository, and decrypting them when you clone / pull, because it means that not even on my development machine are keys just sitting around in plaintext.