I'm trying to understand the concept behind the authentication token in Spring Vault and how a deployment chain would look like?
Everywhere i read, i see that the authentication token has to be provided statically someway or the other and i don't understand how this is secured? if i use a vault to store my secrets securely and not just lying around in a properties file, then why keeping the token in one?
When i just started reading about Vault i was expecting a 'human interaction' phase where the token is provided as a system argument or something at the very last moment before an application is deployed / starts up.
Additionally, i don't see how Vault can fit with a fully automated deployment chain. My Jenkins builds automatically whenever my master branch is changed and will publish the jar and run it via ssh to a designated machine. From what i understand with Vault this cannot be the way i publish my applications, is that correct?
Your post contains multiple questions that are mostly about trust.
The authentication mechanism depends on at least:
For some environments, Vault with a static token is perfectly fine whereas other scenarios require multi-factor authentication. With a static token, you can use a single token across all your apps/app instances or different tokens per app/app instance. This way you can lock out a particular token while others remain valid.
Maybe viewing the question from a different perspective can help: What requirement are you trying to address with Vault? How much effort are you willing to spend on the secure introduction problem?
Vault uses tokens as general authentication mechanism, but it's not limited to that. You can use client certificates, multi-factor authentication, and a few other mechanisms to obtain a session token which is then kept in memory.
It depends on your environment and the risk you're willing to take. You can supply static tokens, generally speaking, a config property, to any Java application with at least the following ways:
Each possibility comes with its own properties and effort to implement. If your runtime/container has sufficient (that's a level you define) protection, a property file can be totally fine. If your requirement is to raise the security bar higher, you maybe want to enter the token during app start with a prompt.
That's not exactly a question but maybe the most interesting sentence in your post.
When you today deploy using Jenkins and SSH, this means, you trust the Jenkins machine and the operator actually performing the deployment. In this arrangement trusting Jenkins seems to be an acceptable risk because the authentication to your runtime is part of your Jenkins setup. The question that arises from here is: Do you trust your runtime? Until which level do you trust it? If you don't trust your runtime (i.e., runtime environment divulges secrets, and unintended parties can easily gain access to it), then you might have bigger issues than a static token.