KMS-PKI Workers #3101
Merged
KMS-PKI Workers #3101
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
jefferai
force-pushed
the
jefferai-kms-workers-nodee
branch
7 times, most recently
from
94fb4ba
to
13c1162
Compare
![github-advanced-security[bot]](https://avatars.githubusercontent.com/in/57789?s=60&v=4){kind=small}
jefferai
force-pushed
the
jefferai-kms-workers-nodee
branch
3 times, most recently
from
1ff1956
to
cb78b76
Compare
jefferai
force-pushed
the
jefferai-kms-workers-nodee
branch
from
cb78b76
to
24fb4fc
Compare
irenarindos
reviewed
Mar 20, 2023
irenarindos
reviewed
Mar 21, 2023
talanknight
reviewed
Mar 22, 2023
talanknight
reviewed
Mar 23, 2023
This adds a new mechanism for worker authentication that uses the third-party arbitration of the original KMS flow by leveraging recently-added capabilities in nodeenrollment to support a registration wrapper. This allows for workers to be registered to the system with just a name and a matching wrapper, while at the same time allowing these workers to be used for private Vault access and multi-hop as they contain per-worker encryption keys and support rotation. Nodes using this mode will generate and rotate credentials in-memory (using another recently added nodeenrollment capability) so will have a new set of keys on every startup. This has the side effect of ensuring that there is never a conflict or re-use of these credentials. Note that the normal test worker flow was using the now-deprecated KMS method; there is still a test that uses this (explicitly) but all other tests using test workers that did not specify a specific PKI flow now actually use this mechanism. This means there is fairly decent test coverage in a general sense, plus the specific tests updated/added for this feature. In a follow-up PR I will add a new KMS type that can be used to have distinct KMSes for upstream authentication vs. accepting from downstream.
This adds an alternate KMS that can be used to handle incoming downstream connections for PKI-KMS registration. This can be specified multiple times; because the upstream only needs to decrypt, we can simply use a PooledWrapper and add each given KMS to the pool.
…er auth in all cases
jefferai
force-pushed
the
jefferai-kms-workers-nodee
branch
from
fe7c4f7
to
6814743
Compare
jimlambrt
approved these changes
Mar 30, 2023
talanknight
approved these changes
Mar 30, 2023
johanbrandhorst
pushed a commit
that referenced
this pull request
May 31, 2023
* KMS-PKI Workers (#3101) This adds a new mechanism for worker authentication that uses the third-party arbitration of the original KMS flow by leveraging recently-added capabilities in nodeenrollment to support a registration wrapper. This allows for workers to be registered to the system with just a name and a matching wrapper, while at the same time allowing these workers to be used for private Vault access and multi-hop as they contain per-worker encryption keys and support rotation. Nodes using this mode will generate and rotate credentials in-memory (using another recently added nodeenrollment capability) so will have a new set of keys on every startup. This has the side effect of ensuring that there is never a conflict or re-use of these credentials. Note that the normal test worker flow was using the now-deprecated KMS method; there is still a test that uses this (explicitly) but all other tests using test workers that did not specify a specific PKI flow now actually use this mechanism. This means there is fairly decent test coverage in a general sense, plus the specific tests updated/added for this feature. This also adds a new KMS type that can be used to have distinct KMSes for upstream authentication vs. accepting from downstream. * refact: fix oss refactor of target repository for ent * refact: more merge fixes --------- Co-authored-by: Jeff Mitchell <jeffrey.mitchell@gmail.com>
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 adds a new mechanism for worker authentication that uses the
third-party arbitration of the original KMS flow by leveraging
recently-added capabilities in nodeenrollment to support a registration
wrapper. This allows for workers to be registered to the system with
just a name and a matching wrapper, while at the same time allowing
these workers to be used for private Vault access and multi-hop as they
contain per-worker encryption keys and support rotation.
Nodes using this mode will generate and rotate credentials in-memory
(using another recently added nodeenrollment capability) so will have a
new set of keys on every startup. This has the side effect of ensuring
that there is never a conflict or re-use of these credentials.
Note that the normal test worker flow was using the now-deprecated KMS
method; there is still a test that uses this (explicitly) but all other
tests using test workers that did not specify a specific PKI flow now
actually use this mechanism. This means there is fairly decent test
coverage in a general sense, plus the specific tests updated/added for
this feature.
In a follow-up PR I will add a new KMS type that can be used to have
distinct KMSes for upstream authentication vs. accepting from
downstream.