You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The problem is when using response wrapping, there is no way for the provisioning system to determine the accessor of the newly created secret-id, making lifecycling of the secret-id nearly impossible (ie, destroying the secret-id when it is no longer needed).
Describe the solution you'd like
A solution already exists when creating response-wrapped tokens, in addition to the wrapping_token and wrapping_accessor fields, a wrapped_accessor field is also returned in the response that contains the accessor for the token itself. Extending this pattern to also work when creating AppRole secret-id's would allow the same pattern to be used here as well.
Describe alternatives you've considered
Not using response wrapping, but this exposes the sensitive secret-id to the provisioning system.
Using auth tokens directly, but these are otherwise more difficult to manage than AppRole credentials which generally seem to be the preferred option.
Explain any additional use-cases
The same sort of pattern might also make sense for some other auth methods too, but I'm not familiar enough to say for certain one way or the other.
Likewise for secrets engines that return a lease_id a similar wrapped_lease_id field could make sense too.
Additional context hashicorp/terraform-provider-vault#976 mentions terraform leaking secret-id's when response wrapping is used. I can't see a way to resolve that issue without a change in Vault to expose the wrapped accessor.
The text was updated successfully, but these errors were encountered:
Is your feature request related to a problem? Please describe.
When provisioning an AppRole secret-id, response wrapping is a recommended best practice to avoid exposure of the actual secret-id to intermediate provisioning systems as per eg https://learn.hashicorp.com/tutorials/vault/approle-best-practices?in=vault/auth-methods#approle-response-wrapping
The problem is when using response wrapping, there is no way for the provisioning system to determine the accessor of the newly created secret-id, making lifecycling of the secret-id nearly impossible (ie, destroying the secret-id when it is no longer needed).
Describe the solution you'd like
A solution already exists when creating response-wrapped tokens, in addition to the wrapping_token and wrapping_accessor fields, a wrapped_accessor field is also returned in the response that contains the accessor for the token itself. Extending this pattern to also work when creating AppRole secret-id's would allow the same pattern to be used here as well.
Describe alternatives you've considered
Not using response wrapping, but this exposes the sensitive secret-id to the provisioning system.
Using auth tokens directly, but these are otherwise more difficult to manage than AppRole credentials which generally seem to be the preferred option.
Explain any additional use-cases
The same sort of pattern might also make sense for some other auth methods too, but I'm not familiar enough to say for certain one way or the other.
Likewise for secrets engines that return a lease_id a similar wrapped_lease_id field could make sense too.
Additional context
hashicorp/terraform-provider-vault#976 mentions terraform leaking secret-id's when response wrapping is used. I can't see a way to resolve that issue without a change in Vault to expose the wrapped accessor.
The text was updated successfully, but these errors were encountered: