Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Return wrapped accessor when creating wrapped AppRole secret-ids #12173

Closed
nvx opened this issue Jul 27, 2021 · 0 comments · Fixed by #12425
Closed

Return wrapped accessor when creating wrapped AppRole secret-ids #12173

nvx opened this issue Jul 27, 2021 · 0 comments · Fixed by #12425

Comments

@nvx
Copy link
Contributor

nvx commented Jul 27, 2021

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants