-
Notifications
You must be signed in to change notification settings - Fork 4.4k
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
Ensure RSA keys are at least 2048 bits in length #17911
Merged
Merged
Changes from 5 commits
Commits
Show all changes
8 commits
Select commit
Hold shift + click to select a range
93ccfe4
Ensure RSA keys are at least 2048 bits in length
jm96441n e8209ad
Merge branch 'main' into NET-4173-rsa-key-length-inline-certs
jm96441n f03248a
Add changelog
jm96441n 8ba9e20
update key length check for FIPS compliance
jm96441n 31c65cb
Fix no new variables error and failing to return when error exists from
jm96441n 1854949
clean up code for better readability
jm96441n c7c2c07
Merge branch 'main' into NET-4173-rsa-key-length-inline-certs
jm96441n c9599af
actually return value
jm96441n File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
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
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,4 @@ | ||
```release-note:bug | ||
gateway: Fixes a bug where envoy would silently reject RSA keys that are smaller than 2048 bits, | ||
we now reject those earlier in the process when we validate the certificate. | ||
``` |
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
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
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
given the FIPS work on enterprise, wondering based on the conditional a couple lines below the linked envoy line:
We may want to call:
consul/version/fips.go
Line 5 in b76c4d7
and do some additional constraint checks and only allow you to create InlineCertificates with those exact bit lengths if built with FIPS... since in the FIPS-compliant envoy build (and due to the movement towards packaging envoy FIPS alongside dataplane we should be able to detect since we require the whole stack including the Consul servers to be FIPS-compliant at that point) any other key length will result in the same broken envoy instances... WDYT?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
that's a good call out! lemme modify this a bit
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
One other thing to call out is that you'll want to also do this in the k8s side of things on the gateway validation itself, somewhere like this:
https://github.com/hashicorp/consul-k8s/blob/d3f9b670ab8055f0fc8ea4061c2d3c40abeb047f/control-plane/api-gateway/binding/validation.go#L207-L213
Since we don't do any sort of status syncing to Kubernetes secret objects, invalid certificates referenced by a gateway get statuses reflected back only on the gateway. Rather than attempting a sync and having it be silently rejected by Consul, we should just skip the attempt at InlineCertificate creation and set a status on the Gateway object in Kubernetes saying, "the cert you're referencing has an invalid length" to inform the user.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yeah I've got some code over in the
ParseCertificates
function currently that I'm gonna push up after this merges so implementations are similar-ish and will have mostly been code reviewed already