Skip to main content
Bumped by Community user
added 11 characters in body
Source Link

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

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

  • 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

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

Source Link

Recommended Design - Communication among Jenkins + Vault + App

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

  • 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