Do not store auth token in user home folder

[StyleT]

Currently Vault uses user home folder in Linux to store it's authentication token after vault auth command. It may cause a case when root token will say there forever on some instance of Vault cluster. So attacker can easily pickup it.
Maybe it's better to use shell session env vars for this.

[vishalnayak]

@StyleT vault auth is a totally optional command and is intended to cache the token in the CLI (Caching it on the disk is just the default behavior and can be changed). It makes dev mode easy to work with.

Its possible that the token is only stored in VAULT_TOKEN env variable (without running vault auth) to be able to and run all the CLI commands.

[jefferai]

This might be of interest:

#723 (comment)

[StyleT]

@jefferai @vishalnayak HI! I would say that current default behaviour it's very obvious & may compromise security. Is it possible to add some warning to the CLI output after default vault auth usage that your key was stored on disk & will be available on only inside current SSH/Terminal session?

[vishalnayak]

@StyleT Internally, we were discussing a -no-store option on the command which would authenticate the client but not persist the token on disk.

Such an option would not make sense for the default token authentication since it accepts the token in the first place. There is no need to run vault auth in this case.

For non-token authentication methods like github, ldap, userpass, okta, cert, aws, radius there are handlers that fetch the token. It might be good to just get the token and not persist it in helpers, both internal and external.

will be available on only inside current SSH/Terminal session?

This is incorrect, unless I understood you wrong. CLI will fetch the token from the helper, and for the default internal helper, this means that the token will be fetched from disk. Once authenticated, Vault CLI commands should work across terminal sessions.

Is it possible to add some warning to the CLI output

It might not be a bad idea to detect if the token helper is internal or external. If the helper is internal, we can add a warning to the output. Any chance you can PR this?

[thraxil]

I just ran into this and would like to suggest that if it's not considered a bug, it should at least be mentioned prominently in the documentation. I couldn't find a single mention in all of the vault documentation that using vault auth results in your token getting stored on disk in plaintext. The only mention of ~/.vault-token I could find was on the environment variables page where it mentions that it will default to reading from there if $VAULT_TOKEN isn't set.

[jefferai]

@thraxil It's kind of the point of the command; you have no need to use vault auth specifically (it just makes API calls) so it's really designed specifically for users to get and persist a token.

As Vishal said, we're considering adding a no-store option. Also there is a notion of token helpers, so an external process can be invoked to store/fetch the token, e.g. to store into your OS keychain. Nobody has written any such helpers as of yet, though.

[thraxil]

@thraxil It's kind of the point of the command; you have no need to use vault auth specifically (it just makes API calls) so it's really designed specifically for users to get and persist a token.

This is why I think it's a documentation issue. Going through the Getting Started guide, eg, the CLI is clearly the focus and the REST API is sort of an "oh, you can also do things this way if you want" aside at the end. There's a warning on this page about not putting real secrets on the CLI to avoid them getting into your shell history, so that gives the impression that there's been some thought put into that sort of thing. And vault auth - seems to exist precisely so you can authenticate without leaking your token into your shell history. It doesn't seem unreasonable to conclude that the official CLI that is used all through the documentation is actually the recommended tool for interacting with vault for basic admin tasks.

If the official view is really that you should only use the APIs and the CLI is just a toy for getting started and that anyone using vault in production should write their own administrative interfaces against the API instead of using the included tools, the documentation does not give that impression.

[jefferai]

That's not the official view, but most users use something like envchain to store their token rather than ~/.vault-token if they find this concerning. It seems like adding a -no-store option would address these concerns.

[tomdottom]

If anyone wishes to control the vault token location with a VAULT_TOKEN_PATH env var then an example solution using the token helper can be found at #1492 (comment)