search

uber-node / zero-config

A zero configuration configuration loader
MIT License
116 stars 10 forks source link

./config/secrets loading interface and order needs to match the ./config loading interface and order #19

Open lxe opened 9 years ago

lxe commented 9 years ago

I think we need to change the current interface of loading secrets in the context of environments.

We used to load config/secrets/secrets.json regardless of NODE_ENV, but after https://github.com/uber/zero-config/pull/17, secrets/secrets.json gets loaded iff NODE_ENV === 'production'

The interface to load the 'normal, non-secret config' is pretty nice:

  1. Load config/common.json
  2. If NODE_ENV is set to foo, load config/foo.json
  3. ...
  4. Profit

Adding secrets, now we have this:

  1. Load config/common.json
  2. If NODE_ENV is set to foo, load config/foo.json
  3. If NODE_ENV is set to foo, load config/secrets/secrets-foo.json...
    • Unless NODE_ENV is set to production, in that case config/secrets/secrets.json
  4. ...
  5. Cry

There's no reason to complicate the secrets interface. Why not do this???:

  1. Load config/common.json
  2. If NODE_ENV is set to foo, load config/foo.json
  3. Load config/secrets/common.json
  4. If NODE_ENV is set to foo, load config/secrets/foo.json
  5. ...
  6. Profit

cc @sh1mmer @Raynos @mlmorg

sh1mmer commented 9 years ago

My understanding was that unlike other environment which can have inheritance we actively want to discourage developers from sharing secrets between environments. Hence that approach.

lxe commented 9 years ago

I think a consistent interface is worth more than guiding the user towards certain behavior.

sh1mmer commented 9 years ago

I understand your position. I think consistency of interface is important but sharing or leaking secrets between environments is something we actively consider an anti-pattern. The interface for specify things per NODE_ENV environment still works e.g. secrets-development.json and secrets-test.json, etc if you need something in another environment. I'd be amiable to naming them to secrets/test.json or testing for both.

rajeshsegu commented 9 years ago

I am trying to move a web project on to zero-config. I have secrets same for both development and production. I wish there was something like "config/secrets/common.json" which might make it more cleaner and remove unnecessary redundancy.

cc @lxe @mlmorg @sh1mmer

Raynos commented 9 years ago

The original common.json was a mistake. Even if we added one you would still need to ask Langley for this feature.

At this point we should favor having no more moves. The semantics are already complicated enough. Just let it be.

Raynos commented 9 years ago

@rajeshsegu think very, very carefully about what you just said.

Your saying you want to deploy the same secrets, the same passwords to a development machine; a public machine on the Internet AND to a production machine; a private machine in the data center.

This means your putting our production secrets on the public internet. Congratulations.

lxe commented 9 years ago

@raynos this is a configuration loader. There's nothing in the code that secures or ensures security of your secrets.

The way the secrets are offloaded and secured and then consumed by various machines has nothing to do at all with zero-config.

rajeshsegu commented 9 years ago

@Raynos Think about things like twitter { consumer_key, consumer_secret, .. }, s3 { accessKeyId, secretAccessKey }, googleMapsApiKey{} which is not going to be different for either development or production. Is the right design to generate multiple keys for development & production ? ( not sure how flexible it is )

If your argument is right, these details would live inside config/common.json or just be redundant in multiple secrets.