Configuring a static Vault token in Jenkins is a relatively major violation of Vault's security model, which relies on finite-lived tokens and authentication. It also relies on the authentication process to limit token use (such as by CIDR block or timeframe).

Using static tokens means that anyone who can somehow read that token from Jenkins configuration and use it outside of Jenkins. A trivial example of this is that anyone with access to the Script Console can simply run:

def desc = Jenkins.instance.getDescriptor("com.datapipe.jenkins.vault.VaultBuildWrapper")
println(desc.authToken)

And see the plaintext token.

I'd like to recommend an alternative:

1. A second configuration option for "Vault Token File", that points to a path on disk (either absolute or, easier, within JENKINS_HOME) that contains the token to use for Vault.
2. Every time the Build Wrapper is run in a job, the contents of that file is read from disk, stripped of whitespace, and used as the token.

A sidecar process (anything else running on the server) is responsible for writing that file. Since it's read as part of every build process, this makes it simple (both overall, and from the plugin's perspective, since all it needs to do is read the file) to have any other process on the system authenticate to Vault and write short-lived tokens (i.e. 1-5 minute lifetime) to that file.

Especially given how Vault's authentication methods are changing, how many there already are, and how complicated some of them can be, this allows the user to manage the out-of-band token provisioning mechanism, while still maintaining the possibility of having short-lived tokens.