Add support for VAULT_TOKEN_FILE env var

[nwoythal]

In some situations, I've found it makes more sense to read the vault token from a local file (e.g. to avoid logging env VAULT_TOKEN=...)

I've skimmed the token helper documentation, and I'm not 100% it fulfills my use-case, since it also requires a file in $HOME, but if running under a user created with either a shared/nonexistant/RO $HOME there could be some trickiness setting up a ~/.vault file.

#20272

TODOs:

• [x] Changelog entry
• [ ] Add tests

[hashicorp-cla]

All committers have signed the CLA.

[maxb]

I'm just another Vault contributor, so don't take what I say as a requirement - but here are some things I think it would be nice to consider:

• Vault has existing code for reading a token file from disk. That code supports the detail of trimming whitespace read from the file, so a newline at the end of the file doesn't mess things up. More generally, re-using that code, so that there is no chance for subtly different semantics, seems like a good idea.

• Currently, I can set VAULT_TOKEN to override any token stored on disk. It would be worth at least discussing whether VAULT_TOKEN should override VAULT_TOKEN_FILE, vs. being an error if both are set.

• Rather than writing a chunk of new separate code for this, what about just having VAULT_TOKEN_FILE override where the existing code, in command/token/helper_internal.go looks for the token?

• This would also allow VAULT_TOKEN_FILE=/other/location vault login ... to write a newly acquired token back to an alternate file.

[maxb]

• Rather than writing a chunk of new separate code for this, what about just having VAULT_TOKEN_FILE override where the existing code, in command/token/helper_internal.go looks for the token?

Now I look at #20272, I see the user there thinks that would be a good solution, too :-)

[nwoythal]

• Currently, I can set VAULT_TOKEN to override any token stored on disk. It would be worth at least discussing whether VAULT_TOKEN should override VAULT_TOKEN_FILE, vs. being an error if both are set.

I'm definitely open to discussing this to hear what the community thinks -- my two cents on the matter is I can see it being the source of confusing errors. E.g. if VAULT_TOKEN is set in a .rc file or env or something and quietly overriding VAULT_TOKEN_FILE. At the very least it should warn the user that it's happening.

• Rather than writing a chunk of new separate code for this, what about just having VAULT_TOKEN_FILE override where the existing code, in command/token/helper_internal.go looks for the token?
• This would also allow VAULT_TOKEN_FILE=/other/location vault login ... to write a newly acquired token back to an alternate file.

I see what you're saying here and agree with the benefits -- I was thinking it would be best to keep the environment overrides in a centralized place, though on second look it seems that's probably not important.

[maxb]

I keep seeing this PR pop up in my GitHub notifications due to repeated force-pushing. I'm not sure there's any point in doing that, @nwoythal.

[nwoythal]

Sorry, just trying to keep it from falling too far behind main. FWIW, the PR has been open for nearly two months now, am I missing something somewhere to mark it as ready for review by the owners? I couldn't find any info in CONTRIBUTING.md, nor on the discussion forum linked there.

[maxb]

Ah, only 2 months... one of mine is still open after 7 months without more than an initial holding response.

Unless you catch the attention of an engineer who happens to already be working in a particular area, HashiCorp can be a difficult entity to contribute to.

Sometimes @hsimon-hashicorp is able to help a bit...

[biazmoreira]

@nwoythal Thanks for your contribution. Before we go into changing the code to introduce a new environment variable, I'd like to confim you've looked into https://www.hashicorp.com/blog/building-a-vault-token-helper? Would that solve your use case?

[nwoythal]

@biazmoreira thanks for the docs -- it seems I missed the ability to override VAULT_CONFIG_PATH to allow for specifying non-standard token helper locations, which might help out with my use-case here.

With that said (and I admit my use-case is a bit niche), this seems like quite a bit of boilerplate to have the user configure, especially for a feature that seems to have been requested more than once (per "Explain any additional use-cases" in #20272).

[biazmoreira]

@nwoythal given your last comment, would it be ok if I went ahead and closed the PR?

[Enissay]

I am confused, was this request rejected ? The suggested token helper file is just not as flexible since the file could be in a different path!

As a workaround we can use in compose/stack file:

command: sh -c 'export VAULT_TOKEN=$(cat /custom/path/token.txt) && server'

But it is not as elegant as using a dedicated VAULT_TOKEN_FILE. Many many projects do support such variables for all critical secrets, I wonder why all the pushback here :-/