Answers: <p>My choice would be design B.</p>
  
  <p>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.</p>
  
  <p>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.</p>
  
Answers: CC BY-SA 4.0
Answers: 2019-11-24T04:17:12.367Z
Answers: 2019-11-24T04:17:12.367Z
Answers: Dan Cornilescu
Body: <p><a href="https://i.sstatic.net/M2m1S.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/M2m1S.png" alt="enter image description here"></a></p>
  
  <hr>
  
  <hr>
  
  <p><strong>Design A: CD tool communicate with Vault to fetch App secrets on its behalf</strong></p>
  
  <ul>
  <li><p>Jenkins ( <em>CD tool</em> ) computes the Vault path according to the app/project &amp; according to which environment the app will be deployed  (qa, staging, prod,...).</p></li>
  <li><p>Jenkins uses the computed path as payload to make a REST call to Vault.</p></li>
  <li><p>Jenkins get key-value pairs as an HTTP response </p></li>
  <li>Jenkins injects these values as ENV variables in the server/container where the app is deployed.</li>
  <li>Then, Jenkins deploys the app itself ( or restart it) after having ENV vars ready.</li>
  <li><p>The application is designed to read these values from ENV variables ( e.g.: <code>process.env</code> in case of NodeJs App ).</p></li>
  <li><p>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.</p></li>
  </ul>
  
  <p><strong>Design B: App communicates directly with Vault to fetch its secrets</strong></p>
  
  <ul>
  <li>Jenkins ( <em>CD tool</em> ) deploys everything except app's secrets.</li>
  <li>Application is environment-aware. It fetches its secrets from Vault thru API call.</li>
  </ul>
  
  <hr>
  
  <p><strong>Design A Concerns</strong></p>
  
  <ul>
  <li>In-transit Encryption of secrets while injecting them from CD tool to App environment.</li>
  </ul>
  
  <p><strong>Design B Concerns</strong></p>
  
  <ul>
  <li>High Availability of Vault is crucial.If it goes down for any reason (.e.g: Network outage), All applications will not be functional.</li>
  </ul>
  
  <p>What's the best design according to you</p>
  
Tags: <jenkins><continuous-deployment><hashicorp-vault><high-availability><secret-management>
Title: Recommended Design - Communication among Jenkins + Vault + App
UserDisplayName: Abdennour TOUMI
ThreadText: # Recommended Design - Communication among Jenkins + Vault + App
  
  (Asked by: username_0 on 2019-10-07)
  
  [![enter image description here](https://i.sstatic.net/M2m1S.png)](https://i.sstatic.net/M2m1S.png)
  
  ---
  
  ---
  
  **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.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
  
  **Tags:** jenkins, continuous-deployment, hashicorp-vault, high-availability, secret-management
  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_1 on 2019-11-24. Score: 1 | Accepted answer
  
  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.
  
  
  ---
  
  