[feat] GWAPI: introduce insecure_skip_verify to ServerTLSSettings

[krinkinmu]

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

[istio-policy-bot]

😊 Welcome @krinkinmu! This is either your first contribution to the Istio api repo, or it's been
a while since you've been here.

You can learn more about the Istio working groups, Code of Conduct, and contribution guidelines
by referring to Contributing to Istio.

Thanks for contributing!

Courtesy of your friendly welcome wagon.

[linsun]

Looks reasonable. Only q i have is naming, would it make more sense to call it consistently with gateway API feature, allow_insecure_fallback

[keithmattix]

I actually kind of like the symmetry assuming that it works the exact same way as the client settings

[krinkinmu]

Looks reasonable. Only q i have is naming, would it make more sense to call it consistently with gateway API feature, allow_insecure_fallback

@linsun as @keithmattix said, I basically went for the current option trying to be symmetric with the naming.

Also @costinm mentioned during the WG meeting that he does not particularly like the AllowInsecureFallback name - we can't really change the name of the field in gateway API, but we don't have to use AllowInsecureFallback in Istio internal protos as this one.

I don't have a very strong opinion, but have a slight preference towards insecure_skip_verify over allow_insecure_fallback due to the above reasons. If you prefer using allow_insecure_fallback, I can change the name, just let me know if you have a strong preference here.