tellerops
Provider authentication configuration
Feature Request
Is your feature request related to a problem? Please describe. I'm currently trying to use the Hashicorp Vault provider. This seems to require me to pass it environment variables. Having a tool to manage environment variables securely requiring environment variables seems somewhat counter-intuitive.
Right now, I seem to need to call teller as such to get my Hashicorp Vault secrets:
$ VAULT_ADDR="https://vault.example.com/" VAULT_TOKEN="mysupersecrettoken" teller show
There are 2 real issues at play here:
- I have to remember for each system which Vault instance to talk to (big organisations may use multiple Vault instances), reducing the usefulness of Teller by requiring out-of-Teller sharing of these environment variables
- My VAULT_TOKEN is in no way protected by Teller from leakage
Describe the solution you'd like It would be good if I was able to configure the authentication for providers in Teller at least partially. Something like this:
providers:
hashicorp_vault:
env_sync:
path: secret/data/{{stage}}/services/billing
config:
VAULT_ADDR: "https://vault.example.com"
(The above example would fix issue 1 and help make Teller a properer source of truth)
Preferably, this would cause an auth flow to happen if the VAULT_TOKEN is not in the environment or not valid, to further reduce the need to store the VAULT_TOKEN insecurely somehow (would solve issue 2).
Describe alternatives you've considered I can't really think of any other way to do this personally.
I believe the original idea here was to rely on "what ever people do when they use vault agent", and then end users load https://www.vaultproject.io/docs/agent/autoauth/sinks/file to env before running Teller.
Putting that aside, we can have teller can also read that file itself.
Maybe @kaplanelad can also throw in a few more alternatives and then basically we need to choose between:
- Leave as is, solve via Vault tooling but still use env-vars as the last-mile to teller
- For the vault provider, add reading from file (the same one + format done by vault agent)
- For all providers, add an option to load a dictionary of values, which will serve as configuration and (sadly) secrets -- only then to recommend that the whole teller.yml file should be ephemeral and generated. Also should be generated as close to usage as possible.
- An alternative to (3) is to add a
config_bin, which is an opaque binary (shell script, program, binary) that teller will run to fetch configuration. This opaque thing can perform ad-hoc authentication, and ultimately need to provide anything that the provider expects implicitly (that is: via env, known-file-locations on disk, or otherwise)
Maybe we need to manage the provider authentication by config "strong" levels (for example, AWS CLI)
For example:
Level 1:
as we have today, keep the environment variable
Level 2:
override level authentication if specified in the provider (Like @TheLastProject example)
Level 3:
if there is a config file in agreed path like ~/.teller/{provider-name}
level 2+3 is for advanced and allows also to work with save provider type and can be a different "cluster"
