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 & 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.envin 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