Support multiple Vault commandline client tokens

[mfischer-zd]

Currently Vault can only manage one local vault token in $HOME/.vault-token. Users at larger sites will likely interact with multiple Vault instances, so it would be useful for Vault to load and save tokens in a file like $HOME/.vault-token-$HASH, where $HASH is a hash (or a prefix thereof) of the remote URL.

For example, if VAULT_ADDR=https://vault.example.com:8200, then the token would be saved to, and loaded from, $HOME/.vault-token-b5852784. (This is based on a SHA-256 hash, using the first 8 significant digits.)

$HOME/.vault-token could still be used to fall back if no URL-specific token file is available.

[mfischer-zd]

My research suggests that this feature won't be trivial to implement without breaking some interfaces. cracks knuckles

[jefferai]

Most users are using external tools like envchain for this.

[mfischer-zd]

Hmm, that's not a bad idea. Investigating now.

[mfischer-zd]

envchain is pretty clever, I must say (though it surprisingly lacks the ability to enumerate environment namespaces). But I'm not sure it's a good substitute in terms of UX.

When a user authenticates via the CLI, the token is automatically saved in the user's home directory. This means the user can perform subsequent CLI operations immediately, without having to manipulate environment variables, as long as the issued token remains valid.

Consider the case where a user re-authenticates to a Vault instance. Currently that's a pretty frictionless operation, since the Vault client will simply overwrite the existing ~/.vault-token file with the newly-issued token. If the user is relying on envchain to store the token, the variable won't be automatically updated.

So either another wrapper will be needed (envchain NAMESPACE vault-update-envchain vault auth ...); Vault could be updated to have an envchain interface; or the user will have to update the database manually. None of these is particularly elegant, except for Vault having an envchain interface, which seems unlikely since it's too OS-specific and better tools are likely to succeed it.

[jimmycuadra]

Our team would really like first class support for multiple vaults in the Vault CLI. It'd be ideal to have something akin to the aws cli's profiles. I imagine something like this:

# ~/.vault/config.hcl

active_vault {
  name = "staging"
}

vault "production" {
  addr = "https://vault.production.example.com"
  token = "abc123"
}

vault "staging" {
  addr = "https://vault.staging.example.com"
  token = "def456"
}

Switching the active vault:

$ vault profile set production

Adding a new vault to the config file:

$ vault profile create my-new-vault -addr=https://vault.whatever.example.com # new vault block added to config file
$ vault auth # token gets added to vault block in config file for the active vault

Explicitly specify the profile for a command:

$ vault -profile=staging read secret/foo/bar

[jefferai]

@jimmycuadra It's not documented super well but the CLI can invoke an external token-helper to provide a token, which could potentially look at e.g. env vars to decide which token to return.

[jimmycuadra]

Another example of using a CLI like this to target multiple instances of a server-side tool that I think is done really well is Kubernetes's kubeconfig format, which is consumed by kubectl and managed through kubectl config. It lets you easily switch between different Kubernetes clusters.

• https://kubernetes.io/docs/concepts/cluster-administration/authenticate-across-clusters-kubeconfig/
• https://kubernetes.io/docs/user-guide/kubectl/v1.6/#config

[sudoforge]

Just here to voice my opinion that having first-class support for multiple vault instances / profiles / tokens would be really nice. I connect to seven different vault addresses each day. Regularly.

Currently, I create a tmux window for each organization, and within the non-ephemeral panes I spawn I set VAULT_ADDR to the appropriate address. This works, but is definitely cumbersome, as I often spawn at least three or four panes per window.

---

quote @jefferai:

It's not documented super well but the CLI can invoke an external token-helper to provide a token, which could potentially look at e.g. env vars to decide which token to return.

This is still putting the responsibility for managing multiple profiles on the user (or external third party), and isn't really a great solution.

[blalor]

There's a Ruby token helper example in the docs. This works exactly as I'd like, except that VAULT_ADDR is set as an env var by the user, and not by the Vault client. It would be great if the token helper interface could be extended to support this lookup natively.

[cooperbenson-qz]

I would really like to see a solution to this. Our organization has a large number of clusters, and I get super frustrated with having vault server -dev obliterate the token for my real cluster when I start it up. I'm investigating tools like this token helper but it has the limitation of requiring environment variables to be set by the user.

What obstacles exist for implementing something similar to Kubernetes' context abstraction for the Vault CLI?

[aphorise]

I feel that this request should be closed as there are already several solutions for managing multiple Vault instances directly on shell with env as noted earlier as well as aliases for example:

alias v1='VAULT_ADDR=https://...:8200 VAULT_TOKEN="..." vault' ;
alias v2='VAULT_ADDR=https://...:8200 VAULT_TOKEN="..." vault' ;
v1 status ;
v2 status ;

There's also other utilities out there that could be of interest like:

• joemiller/vault-token-helper

IMO - other major consideration why this request may not be possible - is the isolation expected with each cluster - and so if the expectation with delivering this request is that CLI should have awareness of two separate context where one could copy from A to B cluster (secrets, etc) then that can itself be seen as leaving gaps for impression of functionality that should not be possible by design.

@mfischer-zd I'm keen to hear if you've considered these options and how this may still be relevant for you.
Anyone one else with a strong opinion why this should be available (or even how) would be welcome to chime in.

PS - seems related to #7159.