Support KVv2 secrets engine #4
Open
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Vault secret storage is powered by a variety of secret engines. As asserted in source code comments of this crate, the specifics of the secrets format are not very well documented, but the official Go client mentions that the format of the
datafield is "up to the secret backend".As a consequence of this, trying to use the secret engine KVv2 with this crate does not work because the
datafield format was changed, leading to deserialization errors in theSecretstruct: KVv1, KVv2.To address this in a straightforward way, let's allow secret data to be deserialized from either of the KVv1 or KVv2 formats. These formats have been tested successfully with the KVv1, KVv2, and Cubbyhole backends. Other backends may be potentially supported too, as long as they share a similar data format.
While at it, I have instructed
serdeto default deserializing alease_durationof 0 in case that field is absent in theSecretresponse. Although I haven't encountered instances where this field is missing in real-world scenarios, the lack of comprehensive documentation (edit: and the explicit warning on the API documentation about how there might be breaking changes even within thev1API version) prompts a defensive approach, assuming the least possible about the response format.