[feat] GWAPI: introduce insecure_skip_verify to ServerTLSSettings#3727
Open
krinkinmu wants to merge 3 commits into
Open
[feat] GWAPI: introduce insecure_skip_verify to ServerTLSSettings#3727krinkinmu wants to merge 3 commits into
krinkinmu wants to merge 3 commits into
Conversation
Signed-off-by: Mikhail Krinkin <mkrinkin@microsoft.com>
The intention is to use this flag to configure Envoy to perform the verification of the client certificate if it's provided, but allow the connection through even if the verification failed. This will be used to implement Gateway API AllowInsecureFallback feature in Istio. The intention behind that feature is to allow connections even when gateway cannot verify the client certificate, but the gateway can then pass the client cert (if it was provided) through to the actual backend (in x-forward-client-cert HTTP header) and backend could potentially verify the cert instead of the gateway. None of the existing TLS modes that Istio supports covers this functionality, so we need some kind of new mode or a flag to indicate that we should allow connections through even if the certificate is not valid. The closest thing we have is `OPTIONAL_MUTUAL` mode, but in this mode Istio will allow connections through if the client does not present the certificate, but if client presents the certificate, Istio will properly verify it and will reject the connection if the cert fails this verification. NOTE: We already have a similar field in the `ClientTLSSettings`, but that's used for verifying certificates on outgoing connections, while this new field in `ServerTLSSettings` controls how gateway will validate the incoming TLS connections. In Istio, by default, Gateways already populates `x-forward-client-cert` header in gateways (it uses `SANITIZE_SET` by default), but it could be overwritten via `GatewayTopology` in the mesh config to not populate the header at all or to append the certificate to the existing header. NOTE: I will followup this PR with anoth PR in Istio repo with implementation that actually uses this new field a bit later (I already have the implementation that passes conformance tests in my own repo, but I need to take another look at it before I send for a review). Signed-off-by: Mikhail Krinkin <mkrinkin@microsoft.com>
|
😊 Welcome @krinkinmu! This is either your first contribution to the Istio api repo, or it's been You can learn more about the Istio working groups, Code of Conduct, and contribution guidelines Thanks for contributing! Courtesy of your friendly welcome wagon. |
istio-testing
added
the
size/S
Signed-off-by: Mikhail Krinkin <mkrinkin@microsoft.com>
This file contains hidden or 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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
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.
The intention is to use this flag to configure Envoy to perform the verification of the client certificate if it's provided, but allow the connection through even if the verification failed.
This will be used to implement Gateway API AllowInsecureFallback feature in Istio. The intention behind that feature is to allow connections even when gateway cannot verify the client certificate, but the gateway can then pass the client cert (if it was provided) through to the actual backend (in x-forward-client-cert HTTP header) and backend could potentially verify the cert instead of the gateway.
None of the existing TLS modes that Istio supports covers this functionality, so we need some kind of new mode or a flag to indicate that we should allow connections through even if the certificate is not valid.
The closest thing we have is
OPTIONAL_MUTUALmode, but in this mode Istio will allow connections through if the client does not present the certificate, but if client presents the certificate, Istio will properly verify it and will reject the connection if the cert fails this verification.NOTE: We already have a similar field in the
ClientTLSSettings, but that's used for verifying certificates on outgoing connections, while this new field inServerTLSSettingscontrols how gateway will validate the incoming TLS connections.In Istio, by default, Gateways already populates
x-forward-client-certheader in gateways (it usesSANITIZE_SETby default), but it could be overwritten viaGatewayTopologyin the mesh config to not populate the header at all or to append the certificate to the existing header.NOTE: I will followup this PR with anoth PR in Istio repo with implementation that actually uses this new field a bit later (I already have the implementation that passes conformance tests in my own repo, but I need to take another look at it before I send for a review).
Signed-off-by: Mikhail Krinkin mkrinkin@microsoft.com