Use internal server certificate for peering TLS #14796
Merged
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
theme/api
freddygv
commented
Sep 29, 2022
freddygv
commented
Sep 29, 2022
|
|
freddygv
force-pushed
the
peering/use-connect-ca
branch
from
0dc9c45 to
2d0f5b6
Compare
freddygv
force-pushed
the
NET-643-update-mesh-gateway-envoy-config-for-inbound-peering-control-plane-traffic
branch
from
0d6d338 to
b15d415
Compare
freddygv
force-pushed
the
peering/use-connect-ca
branch
from
2d0f5b6 to
39e77e8
Compare
Base automatically changed from
NET-643-update-mesh-gateway-envoy-config-for-inbound-peering-control-plane-traffic
to
main
October 3, 2022 18:54
| return b.srv.tlsConfigurator.GRPCManualCAPems(), nil | ||
| // GetTLSMaterials returns the TLS materials for the dialer to dial the acceptor using TLS. | ||
| // It returns the server name to validate, and the CA certificate to validate with. | ||
| func (b *PeeringBackend) GetTLSMaterials(generatingToken bool) (string, []string, error) { |
There was a problem hiding this comment.
I'm probably missing something, but am not seeing the code for falling back to the manually configured
certs. Where does that happen?
There was a problem hiding this comment.
Good catch! We decided to not have that fallback anymore. Since Connect is now required when generating tokens we're just always going to use the internally managed cert.
If someone wants to adjust details about how the CA is managed they can do that by updating the Connect CA config.
I updated the PR description to remove the fallback message.
erichaberkorn
approved these changes
Oct 3, 2022
A previous commit introduced an internally-managed server certificate to use for peering-related purposes. Now the peering token has been updated to match that behavior: - The server name matches the structure of the server cert - The CA PEMs correspond to the Connect CA Note that if Conect is disabled, and by extension the Connect CA, we fall back to the previous behavior of returning the manually configured certs and local server SNI. Several tests were updated to use the gRPC TLS port since they enable Connect by default. This means that the peering token will embed the Connect CA, and the dialer will expect a TLS listener.
By requiring Connect and a gRPC TLS listener we can automatically configure TLS for all peering control-plane traffic.
freddygv
force-pushed
the
peering/use-connect-ca
branch
from
39e77e8 to
3034df6
Compare
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.
Description
#14485 and #14556 introduced an internally-managed server certificate
to use for peering-related purposes.
Now the peering token has been updated to match that behavior:
Testing & Reproduction steps
PR Checklist