Multi-provider secrets

[dustinmm80]

This issue is to track the enhancement of the secrets.yml spec to allow an optional provider specifier. This will allow you to use different providers to resolve secrets in the same secrets.yml file.

Proposal is to add a provider YML field to specify what provider should resolve a secret. If no provider field exists, the default provider is used.

[dustinmm80]

Do we still want this? I get the use case, but this could be solved in many different ways with bash.

[ryanprior]

I don't like the idea of specifying the provider in the secret YAML, because that makes it difficult to use one provider (ie a local keyring) in dev and a different one (eg Conjur) in prod with the same secrets manifest.

Here's my counter-proposal: allow multiple secrets files, each used with a different provider, in one run.

Right now we can already accomplish multi-provider secrets through chaining. We could have conjur-secrets.yml and aws-secrets.yml and do this:

summon \
  --provider conjur \
  -f conjur-secrets.yml \
  summon \
    --provider s3 \
    -f aws-secrets.yml \
    myscript.sh

In order to make this pattern more convenient and less complicated, we could enhance summon to instead accept this syntax:

summon \
  --provider conjur -f conjur-secrets.yml \
  --provider s3 -f aws-secrets.yml \
  myscript.sh

Then I can still use different providers in dev:

summon \
  --provider keyring -f conjur-secrets.yml \
  --provider keyring -f aws-secrets.yml \
  myscript.sh

[jepperson2]

As @ryanprior mentioned, I've gotten around this by running summon -p ... -f ... summon -p ... -f ... myscript.sh, but having a consolidated form of summon -p ... -f ... -p ... -f ... myscript.sh would be nice