-
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
connect: introduce ExternalSNI field on service-defaults #6324
Conversation
(pre-diff-review response). Overall it makes sense to constrain the change to what we need for external sources for now given the complication added by generating SNI inside the compiler. I'm still not super clear on how requiring trust domain in the compiler alters the client watch code - the trust domain is always known on the servers so I was assuming it would just need to be passed in in the RPC handler that invokes compile. We should never need to override the trust domain from a client when invoking compile - it should always just be filled in by the current active TD on the server. Does that change anything? Another option I'm open to if it simplifies things would be leaving the Compiler as you have it here but auto-populating any blank SNI fields in the result in the RPC handler before returning it. The RPC handler should always be able to load the current active trust domain from the state store without any complication. That said, I'm not sure that it's any simpler for the RPC handler to load that and do the default setting itself, vs, loading it and passing it into the compiler to use for default setting? The eventual goal as mentioned in the original PR is that I'd like to lift the SNI logic out of the proxy-specific code so it doesn't have to be duplicated in future proxy integrations. All that said, happy at a high level to land this as described and pick up one of the above options later if you think that's a quicker path to landing this for external overrides. I'll go look at the code now ;) |
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.
Looks awesome, thanks R.B.
See what you think about my comments above. Does it change your assumptions about how hard it would be to apply defaults during Compile too or am I missing something? Either way happy to resolve that later but if we don't do it now, maybe we could make an issue to move SNI defualting to servers so we don't forget?
target.Service, | ||
), | ||
} | ||
} |
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.
Nice, these help make the external thing less confusing when trying to configure features that won't work any more.
Compiling this will set an optional SNI field on each DiscoveryTarget. When set this value should be used for TLS connections to the instances of the target. If not set the default should be used. Setting ExternalSNI will disable mesh gateway use for that target.
2f8cf7b
to
1af4dbd
Compare
Co-Authored-By: Paul Banks <banks@banksco.de>
Compiling with a
service-defaults
entry definingExternalSNI
will set an optional SNI field on each DiscoveryTarget to this value and flag the target asExternal=true
. WhenSNI
is set this value should be used for TLS connections to the instances of the target. If not set the default should be used.Setting ExternalSNI will disable mesh gateway use for that target. It fundamentally alters how the compiler treats the service: Failover, Subsets, and Redirects cannot be configured on an external resolver.
This supersedes #6237. The main difference is this does not shift around all of the SNI generation, just the override aspect for now.
This version avoids some
agent/proxycfg
watch ordering complications that arise if the discovery chain compiler needs to accept a trust domain as an input argument.