Vault: Support multiple Vault commandline client tokens

Created on 14 Nov 2016 · 10Comments · Source: hashicorp/vault

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.

core feature-request

Source

mfischer-zd

👍2

Most helpful comment

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

jimmycuadra on 30 Mar 2017

👍12

All 10 comments

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

mfischer-zd on 14 Nov 2016

Most users are using external tools like envchain for this.

jefferai on 15 Nov 2016

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

mfischer-zd on 15 Nov 2016

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.

mfischer-zd on 15 Nov 2016

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

jimmycuadra on 30 Mar 2017

👍12

@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.

jefferai on 30 Mar 2017

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.

jimmycuadra on 30 Mar 2017

👍3

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.

sudoforge on 12 Apr 2018

👍1

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.

blalor on 4 Dec 2019

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?