Using $VAULT_TOKEN environment variable in transit unseal as suggested by docs breaks custom auth plugins

[shwuandwing]

Description
The docs in transit unseal https://www.vaultproject.io/docs/configuration/seal/transit.html recommends that using the environment variable $VAULT_TOKEN to pass the token used to unseal Vault.

However, if you do that, custom auth plugins get broken because $VAULT_TOKEN is passed into the plugin process --and you end up with cryptic errors when trying to unwrap because the plugin process somehow is using the $VAULT_TOKEN which is a token to access the transit engine for unseal, -- not the token to get the secrets so the plugin can communicate to vault.

plugin tls init: error="error during token unwrap request: Error making API request.

URL: PUT http://127.0.0.1:8200/v1/sys/wrapping/unwrap
Code: 403. Errors:

• permission denied" timestamp=2019-07-23T17:59:27.227-0700

It looks similar to the error mentioned in this thread.
https://groups.google.com/forum/?utm_medium=email&utm_source=footer#!msg/vault-tool/twO5nK-40nc/skGKvvsHDAAJ and this github issue
#4630

Steps to reproduce the behavior:

1. Setup Vault to use transit unseal, pass in token using environment variable VAULT_TOKEN
2. Try to enable a custom auth plugin
3. See error

Expected behavior
It should be possible to pass the Vault token for transit using environment variable AND use custom auth plugin.

Version it occured on
Vault 1.1.2

Or else it should be documented combination does not work

[voiprodrigo]

Hi. I'm running 1.6.1 with transit unseal and I'm facing this exact issue. I set the unseal token via an EnvironmentFile loaded by the vault systemd service. Then as soon as I mount a secrets path using the custom plugin , I see in the logs the 403 for the unwrap endpoint. Any suggestion? Thanks.

[voiprodrigo]

I disabled the unseal token, and the custom plugin now works as expected. So I believe that #8058 does not address this.