[ebarriosjr]

No description provided.

[jrasell]

@ebarriosjr thanks a lot for this. Before I merge this in I am curious what is secure introduction method will be when supplying a token via the CLI?

[ebarriosjr]

@jrasell I believe supplying the token via the cli is not secure. Depends mostly on how you use Levant. I would say that the recommended way will be to use the env variable but it is nice to have the possibility of sending the token via the cli for testing imho.

[redfive]

This patch always uses the env var VAULT_TOKEN if it exists, as long as no command line switch is passed in? Just thinking if that would get troublesome in CI environments that might have a more permissive token set in the environment by default.

[ebarriosjr]

Hi @redfive
you are right. If the token is set in the CI env for this job then it is going to use it. I could amend the merge request if needed to add a flag to enable or disable the loading from env. I usually set the token by job and not for the entire environment in our CI. Maybe @jrasell has an opinion about this?

[jrasell]

@redfive raises a nice point where unintentional side effects could arise if the user doesn't understand the internals of the CLI flag. Taking this into consideration @ebarriosjr, how would you feel about having this flag only as an explicit CLI passed variable, and adding another which would read the env var (I would guess they would be exclusive and you can only provide one of the two)?

[ebarriosjr]

@jrasell I worked on it as promised and now we have two flags:
-vault -> will load the vault_token from the env
-vault-token -> will load the vault_token from the cli
If both of them are used at the same time an error would occur.

[jrasell]

thanks a lot @ebarriosjr