Support Config File for Vault Client

[dragonndev]

When using vault as a client app (when unsealing for example) it would be nice if you could specify a client config like you can for the server config. Having to specify the address and ca-cert path variables on each CLI call is rather cumbersome.

[armon]

Great idea! Tagged!

[ianunruh]

An easy solution you may consider is creating a script and sourcing it before using the client.

#!/bin/bash
export VAULT_CAPATH=XXX
export VAULT_TOKEN=XXX
export VAULT_ADDR=XXX

chmod 640 vaultrc
source vaultrc
vault unseal XXX

Obviously putting your token in plaintext on the filesystem isn't the most secure method in the world, but setting filesystem permissions helps a bit.

This technique is commonly used for "configuring" CLI clients, especially in the OpenStack ecosystem.

[rhoml]

Is there any news on this issue?

[jefferai]

@rhoml No news yet, sorry.

[rhoml]

I think a great approach to this can be if we could expand .vault-token file capabilities. Currently I just load this parameters using a zsh function.

[stvdilln]

+1, I made a shell script (as ianunruh) to set these and sent them out to the team. I then got asked for a .cmd windows version, then a powershell version, then a cygwin version. The HCL format of the settings reduces some this (albeit small) problem.

I also would like to specify an externalTokenHelper for the client and don't see how to do this without the client using a config file.

[tyrannosaurus-becks]

Hi! Is this solved by the Vault agent config file? https://www.vaultproject.io/docs/agent/index.html. The agent is an automated Vault client that pushes a token out to somewhere easy for you to consume from another application. Currently it pushes tokens out to a file.

[aphorise]

Any environment export statement that's required to be set in the shell of most common Operating Systems are only a single line - eg:

• Linux / bash:

  export VAULT_ADDR=… VAULT_TOKEN=… VAULT_CAPATH=… ;
  # // we continue with using vault

• Windows / powershell:

  $env:VAULT_ADDR="…" ; $env:VAULT_TOKEN="…" ; $env:VAULT_CAPATH="…" ;
  # // we continue with using vault

What's am I not getting? - Is this issue still applicable?

[oliverisaac]

A config file would still be helpful. It'd be very slick to have the concept of "contexts" (like in kubectl), but even a static config file could be swapped out by some sort of vaultctx-like tool to provide the same multi-context functionality.

[aphorise]

@dragonndev (@oliverisaac & others too) - Hey I was curious how of this request may be possible using:

• joemiller/vault-token-helper

PS - May be related to #7159 & #2092

[melezhik]

hi guys, any progress here?

[aphorise]

Additional to what I mentioned earlier

joemiller/vault-token-helper

there's also:

• github.com/gothrek22/vault_switcher

I personally am of the opinion that this request should be closed especially if it's not going to be developed prior to it's 10th year anniversary :-)

[cognifloyd]

I would like a config file that allows me to update the defaults for login parameters.

For example, I wish I didn't have to set the oidc addresses when logging in on a remote VM with OIDC method:

vault login -method=oidc listenaddress="..." callbackhost="..."

https://support.hashicorp.com/hc/en-us/articles/15874139143955-OIDC-Login-via-CLI-on-a-Headless-Server
https://developer.hashicorp.com/vault/docs/auth/jwt#oidc-login-cli

Extending the ~/.vault config file would be ideal: https://developer.hashicorp.com/vault/docs/commands/token-helper