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.”
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
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
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.