Backport of refactor identity claims constructor to builder into release/1.8.x #23741
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.
Backport
This PR is auto-generated from #23708 to be assessed for backporting due to the inclusion of the label backport/1.8.x.
The below text is copied from the body of the original PR.
Upcoming work to add extensibility to identity claims for Vault (ref #23510) will require exposing server configuration and more objects from state to the process of creating an
IdentityClaims
struct.Depending on how we inject these parameters into the constructor, we end up creating circular dependencies or a lot more logic in the setup in the plan applier and alloc endpoint. There are three contexts where we call
NewIdentityClaims
: the plan applier (where we only care about the default identity), signing task identities, and signing service identities. Each needs different parameters. So we'll refactor the constructor as a builder with methods that the caller can decide to use (or not) depending on context. I've pulled this work out of #23675 to make it easier to review separately.Ref: #23510
Ref: #23675
Ref: https://hashicorp.atlassian.net/browse/NET-10372
Ref: https://hashicorp.atlassian.net/browse/NET-10387
Note for reviewers: #23675 has some new consumers of this API that'll make it a little more clear why a functional options approach wasn't desirable here. We don't necessarily have all the options ready at once unless we allocate a slice of function pointers to append to, and it makes the already "meh" ordering requirements here easier to mess up.
Overview of commits