Scenario Integrating Jenkins with Vault when 1. Pipelines run both on prem and on cloud 2. You cannot always use Vault Auth Methods like AWS or Kubernetes
Rely on Vault AppRole auth method "The AppRole auth method allows machines or apps to authenticate with Vault-defined roles by providing a sort of username/password credentials data to login into Vault, retrieve a token and use it to interact with Vault.”
Whoami Sr DevOps Engineer at Yoox-Net-A-Porter Group trying to integrate Vault as much as possible in my organization linkedin.com/in/giuseppe-misurelli-5378202
Leverage Vault response wrapping Deliver a wrapped Secret ID token One time action Vault response wrapping ensures that only the interested pipeline unwraps the token and see the Secret ID. Hardening Secret ID The value being transmitted across the wire is not the actual Secret ID but a reference to it. Limit secret exposure The lifetime of the wrapping token is different (and usually much shorter) than the Secret ID one
The new workflow Vault AppRole auth method with response wrapping 1. Vault provides to Jenkins a token with permissions to only write a wrapped Secret ID 2. Jenkins writes a wrapped Secret ID exposing it to the pipeline 3. The pipeline unwraps the Secret ID and uses it with the Role ID to login into Vault
Key points to consider Moving further a more secure implementation... Alerts on misuse Since a wrapped token can only be unwrapped once, an alert can rise each time the proper application cannot unwrap the token meaning that something else unwrapped its token. Secret IDs delivery A Jenkins node can run different pipelines for different applications accessing different secrets. It is crucial that Jenkins wraps the proper secret path to pass to the pipeline. Trusted entity Your Jenkins should be considered as a trusted entity for Vault. Trusted entity that must be secured and treated as a critical system.