When using the Vault agent without templating, how does one retrieve secrets? Via the usual Vault API, except that you’ll be interfacing with the agent instead of the server? The docs seem a bit confusing on this.
And then that begs the question - what are the advantages of doing this vs interfacing with the Vault server directly?
In general interfacing with the Vault server is the “best” in terms of security, functionality, integration, etc. however it has the requirement to make changes to the application to achieve this. Hence the other options - you can run a side car, proxy or operator which handles all the Vault specific stuff and allows your application to just read an environment variable or file. That decoupling might be vital where you are working with 3rd party applications that you can’t modify & don’t have native Vault support. But you might find limitations, or the increased risk of exposing secrets (e.g. if you misconfigure file permissions). Even with one of these other options you still might need some level of fuctionality to support this within the application. For example, if a file is created containing database credentials you’d really want support for change detection so that you can seamlessly update credentials/use dynamic secrets - some of the options can restart the application if secrets are changed, but that may cause outages or other impacts compared to detecting the change within the application.
Excellent info - thanks for the in-depth reply. The application we intend to use with Vault is internally built and can easily be modified to interface to our Vault server, so I’m not sure there’s any benefit to using the agent for us. Plus, it would be one more ‘thing’ to maintain.
I think AppRole is the most common option. Getting the AppRole secret to the application is commonly done via whatever application deployment mechanism you use (e.g. Ansible, Cloud-init, etc.)
Another common option would be to use IAM authentication via your cloud provider.