Comprehensive and Detailed in Depth Explanation:
The screenshot highlights Vault’s response wrapping feature, accessible via the UI’s “Wrap” option. This feature wraps a Vault response (e.g., a secret or token) in a single-use token with a configurable TTL, ensuring secure delivery to an intended recipient. Let’s evaluate each option against this capability:
Option A: Using a short TTL, you could encrypt data in order to place only the encrypted data in Vault This misinterprets response wrapping. Wrapping doesn’t encrypt data for storage in Vault; it secures a response for transmission outside Vault. Encryption for storage would involve the Transit secrets engine, not wrapping. The TTL in wrapping limits the wrapped token’s validity, not the data’s encryption lifecycle. This option conflates two unrelated features and is incorrect. Vault Docs Insight: “Response wrapping does not store data in Vault; it delivers it securely to a recipient.” (No direct storage implication.)
Option B: Encrypt the Vault master key that is stored in memory The master key in Vault is already encrypted at rest (in storage) and decrypted in memory during operation using the unseal process (e.g., Shamir shares or auto-unseal). Response wrapping doesn’t interact with the master key—it’s a client-facing feature for secret delivery, not an internal encryption mechanism. This is a fundamental misunderstanding of Vault’s architecture and wrapping’s purpose. Incorrect. Vault Docs Insight: “The master key is managed by the seal mechanism, not client-facing features like wrapping.” (See seal/unseal docs.)
Option C: Encrypt sensitive data to send to a colleague over email This aligns perfectly with response wrapping. You can retrieve a secret (e.g., vault read secret/data/my-secret), wrap it with a short TTL (e.g., 5 minutes), and receive a token (e.g., hvs. < token > ). You email this token to a colleague, who unwraps it with vault unwrap < token > to access the secret. The data is encrypted within the token, secure during transit, and expires after the TTL. This is a textbook use case for wrapping. Correct. Vault Docs Insight: “Response wrapping… can be used to securely send sensitive data to another party, such as over email, with a limited lifetime.” (Directly supported use case.)
Option D: Use response-wrapping to protect data This is the essence of the feature. Wrapping protects data by encapsulating it in a single-use token, accessible only via an unwrap operation. For example, vault write -wrap-ttl=60s secret/data/my-secret returns a wrapped token, protecting the secret until unwrapped. This ensures confidentiality and controlled access, making it a core benefit of the feature. Correct. Vault Docs Insight: “Vault can wrap a response in a single-use token… protecting the data until unwrapped by the recipient.” (Core definition.)
Detailed Mechanics:
Response wrapping works by taking a Vault API response (e.g., a secret’s JSON payload) and storing it in the cubbyhole secrets engine under a newly generated single-use token. The token’s TTL (e.g., 60s) limits its validity. The API call POST /v1/sys/wrapping/wrap with a payload (e.g., { " ttl " : " 60s " , " data " : { " key " : " value " }}) returns { " wrap_info " : { " token " : " hvs. < token > " }}. The recipient uses vault unwrap hvs. < token > (or POST /v1/sys/wrapping/unwrap) to retrieve the original data. Once unwrapped, the token is revoked, ensuring one-time use. This leverages Vault’s encryption and token system for secure data exchange.
Real-World Example:
You generate an API key in Vault: vault write secret/data/api key=abc123. In the UI, you click “Wrap” with a 5-minute TTL, getting hvs.XYZ. You email hvs.XYZ to a colleague, who runs vault unwrap hvs.XYZ within 5 minutes to get key=abc123. After unwrapping, the token is invalid, and the secret is safe from interception.
Overall Explanation from Vault Docs:
“Vault includes a feature called response wrapping. When requested, Vault can take the response it would have sent to an HTTP client and instead insert it into the cubbyhole of a single-use token, returning that token instead… This is useful for securely delivering sensitive data.” The feature excels at protecting data in transit (e.g., email) and enforcing one-time access, not internal key management or storage encryption.
[Reference: https://developer.hashicorp.com/vault/docs/concepts/response-wrappingAdditional Reference: https://developer.hashicorp.com/vault/docs/secrets/cubbyhole, ]
