sys: adds identity_token_key to mounts/auth for enable/tune #24962
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
github-actions
bot
added
the
hashicorp-contributed-pr
austingebauer
commented
Jan 19, 2024
austingebauer
commented
Jan 19, 2024
|
Build Results: |
|
CI Results: |
vinay-gopalan
approved these changes
Jan 19, 2024
austingebauer
commented
Jan 22, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
This PR adds the
identity_token_keyconfiguration parameter to the sys/mounts and sys/auth APIs. This enables the plugin mounts to specify which identity token key will be used to sign their plugin identity tokens at enable and tune time.I decided to make an empty string the default instead of auto-populating the default key in all mount configs. This means the
identity_token_keyconfig value will be omitted from the mount config unless explicitly specified at enable/tune time. I made this decision in order to not needlessly add another key/value pair to the mount config (required updating of many tests). If the field is unset/empty, we'll always use the default key. This behavior will be documented.A separate PR will add the parameter to the Vault CLI.