2

enter image description here

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

Improve this question

1 Answer 1

Reset to default
1

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.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.