Recommended Design - Communication among Jenkins + Vault + App Design A: CD tool communicate with Vault to fetch App secrets on its behalf


Jenkins ( CD tool ) computes the Vault path according to the app/project &amp; according to which environment the app will be deployed  (qa, staging, prod,...).
Jenkins uses the computed path as payload to make a REST call to Vault.
Jenkins get key-value pairs as an HTTP response 
Jenkins injects these values as ENV variables in the server/container where the app is deployed.
Then, Jenkins deploys the app itself ( or restart it) after having ENV vars ready.
The application is designed to read these values from ENV variables ( e.g.: process.env in case of NodeJs App ).
If the server/container is restarted/rebooted, it is configured to call the same Vault API to bring again the key-value pairs before the app is started.


Design B: App communicates directly with Vault to fetch its secrets


Jenkins ( CD tool ) deploys everything except app's secrets.
Application is environment-aware. It fetches its secrets from Vault thru API call.




Design A Concerns


In-transit Encryption of secrets while injecting them from CD tool to App environment.


Design B Concerns


High Availability of Vault is crucial.If it goes down for any reason (.e.g: Network outage), All applications will not be functional.


What's the best design according to you
My choice would be design B.

It's true that the availability of the Vault would be crucial, but Jenkins' availability would similarly be crucial in design A. So from this perspective the decision would normally be driven by the comparison of the two availability figures, if available. Based on its functionality I suspect that Jenkins is likely to be a more complex tool than Vault (but I don't have any hard data supporting it). If that's correct then Jenkins would normally have a lower availability/reliability score.

A slightly different aspect of the dependency on Jenkins in design A isn't exactly appealing: Jenkins' job normally ends once it successfully deploys a certain version of the app, it isn't really designed to be around to "support" that app version during its expected lifetime (that includes restarting the app). Other tools are better suited to perform app monitoring and management in general. The app's independence from Jenkins that design B brings is, IMHO, an advantage from this perspective.