Vault login from one term overrides token from another terminal

Hi all

Was trying out token APIs and saw the following. Is this expected?

  1. vault server started in -dev mode.
  2. I created two policy files pointing to two different paths - secret/data/app1 and secret/data/app2
  3. Created two tokens with one policy each tied to different paths.
  4. Created two new terminal windows (separate bash shells) on the same machine simulating two apps.
  5. After setting vault_addr env variable, i did ‘vault login token=token_app1’ in one terminal and ‘vault login token=token_app2’ in the second terminal.
  6. When I print ‘vault token lookup’ in the first terminal, I see that the token information points to the ‘token_app2’ information.
  7. When I try the other way around - i could see that whichever token logged in last, that token is seen/shown in the token information field. In fact, i was able to write to App2 path location from the terminal meant for App1 and vice versa.
  8. If I use just environment variable VAULT_TOKEN in these two terminals AND NOT DO vault login from either, everything works as expected.

Am i doing some steps wrong or missing some steps?

Thanks
Srihari

Hi @Sristuff – that is expected behavior. The default behavior of vault login is to store the token in ~/.vault-token and so one vault login command will override the other. Then, on subsequent operations, Vault, if no VAULT_TOKEN environment variable is present, will look up the token from ~/.vault-token.

If you want to preserve different Vault authentication contexts across different terminals, as you noted, you will need to store the Vault token in the VAULT_TOKEN environment variable. If you are using different authentication methods, you can do something like export VAULT_TOKEN=$(vault login -token-only ...) and that will store the Vault token in just the local environment variable.

Thanks much for your time and reply.

One, hopefully final, follow-up query on this subject. Is this not a security issue, if you consider the following steps.

  1. Say, APP1 (a malicious coke-app) - issued a ‘vault login’ from its terminal from machine A - with its token to the centrally hosted Vault instance.
  2. APP2 (pepsi-app) issued its own ‘vault login’ from its terminal from machine B - with its own token to the same Vault instance running in a central location.
  3. If I understand you correctly, the current login cached in ~/.vault-token is the ‘pepsi-app’ token.
  4. Now, if APP1 (being malicious) removed/deleted its own vault_token environment variable and accessed Vault - and tried to read APP2 data location…
  5. Will APP1 now be able to access APP2 data ? - as Vault used the cached ~/.vault-token.

Thanks
Srihari

Hi @Sristuff,

A few thoughts on this.

First, in general, the vault login command is mostly just a helper that can be used to exchange some external authentication data (such as a username/password) for a Vault authentication token, and then caches that Vault token for later use. If you don’t find the behavior of the vault login command acceptable for your security posture (and it has a number of different options, so I would encourage you to understand them, especially including the -token-only and/or -no-store options), then you always have the freedom to issue Vault API commands directly to retrieve the Vault token and handle it in a way that you deem acceptable.

Second, the vault CLI tool that you use to run vault login commands stores the resulting Vault token on the local HOME directory. In your scenario, you have pepsi and coke running on different machines. As long as the users running those commands on the two different machines don’t have some sort of shared HOME directory that allows the two users on the two systems to access each other’s files, then it shouldn’t be a problem. However, if coke on system A can access pepsi’s files on system B, then yes, what you have described would be a problem for you. But, ultimately, I believe it’s the responsibility of pepsi to ensure that its Vault token isn’t stored somewhere that coke can read it. and vice versa.

Lastly, keep in mind that the vault CLI tool reading preferentially from the VAULT_TOKEN environment variable is just a convention. In your scenario, coke wouldn’t need to unset the VAULT_TOKEN environment variable. coke could just have a malicious program that ignored VAULT_TOKEN and instead always tried to read ~/.vault-token. That’s why you need to ensure that any process that stores a Vault token (including vault login) stores the token in an appropriately secured location.