Issues accessing the SNI (server name) from the TLS inspector within External Authorization CheckRequest

[marc-barry]

Title: Access the SNI (server name) from the TLS inspector within External Authorization CheckRequest

Description:

We make use of External Authorization as both a network and HTTP filter. In both cases we set the include_tls_session value to true. For the documentation is states:

(bool) Specifies if the TLS session level details like SNI are sent to the external service.
When this field is true, Envoy will include the SNI name used for TLSClientHello, if available, in the tls_session.

When include_tls_session is set to true one would expect that service.auth.v3.AttributeContext.TLSSession is set. I have ensured that https://www.envoyproxy.io/docs/envoy/latest/configuration/listeners/listener_filters/tls_inspector is set and can confirm that in all cases %REQUESTED_SERVER_NAME% is populated in the logs. I am using the SNI dynamic forward proxy to route the traffic based on the SNI.

Is there possibly an issue with the SNI being sent to External Authorization when using the TLS Inspector? Is there another way I can access the SNI if this manner isn't working properly? Perhaps through some form of metadata that comes across in the CheckRequest.

Note, I have built the authorization endpoint with gRPC using https://github.com/envoyproxy/go-control-plane. i.e. handling the requests with Check(ctx context.Context, req *auth.CheckRequest) (*auth.CheckResponse, error).

Relevant Links:

• https://www.envoyproxy.io/docs/envoy/latest/api-v3/extensions/filters/network/ext_authz/v3/ext_authz.proto#envoy-v3-api-msg-extensions-filters-network-ext-authz-v3-extauthz
• https://www.envoyproxy.io/docs/envoy/latest/api-v3/extensions/filters/http/ext_authz/v3/ext_authz.proto#envoy-v3-api-msg-extensions-filters-http-ext-authz-v3-extauthz
• https://github.com/envoyproxy/go-control-plane

[phlax]

cc @ggreenway @KBaichoo @esmet @tyxia

[ggreenway]

The documentation isn't clear about this, but include_tls_session only works when using a tls transport socket. This could probably be fixed to also work with TlsInspector; a PR to do that would be welcome.

[marc-barry]

@ggreenway Thanks for the clarification. Are you able to give me a few hints about where to look in the code about where the external auth looks at the transport socket when include_tls_session is true? I presume I could just read the server name from SNI (i.e. TLS inspector) and then are probably filters that already read it like the SNI dynamic forward proxy.

[ggreenway]

Start by looking here and here. And then look at how the sni dynamic forward proxy is looking it up, and in CheckRequestUtils::setTLSSession if the existing path is empty, check the value from tls inspector.

[marc-barry]

@ggreenway #34100 is my attempt to handle this. I'm having troubles understanding what exact unit test (or tests) that I broke. I know the file, just not which tests.