Envoy Client Certs for Ext Auth and Backend TLS

[arkodg]

Description:

Describe the issue.

Raising this PR to make a decision on which client certs to use when originating a TLS connection to ext Auth and Backend TLS (relates to https://github.com/kubernetes-sigs/gateway-api/discussions/2743)

Option 1 Reuse Listener (Downstream) certs

Option 2 Define a common proxy cert in the EnvoyProxy config

Option 3 (not possible today) Define certs in each config

• within the SecurityPolicy.ExtAuth.TLS field
• not possible in BackendTLS, since its a upstream API

[arkodg]

ptal @envoyproxy/gateway-maintainers

[zhaohuabing]

EG doesn't use a global root ca like Istio does. So the problem of the first two approaches is that existing ext auth and jwt services may not be able to verify the client certs.

[arkodg]

EG doesn't use a global root ca like Istio does. So the problem of the first two approaches is that existing ext auth and jwt services may not be able to verify the client certs.

@zhaohuabing imo its a matter of sharing the CA (which is meant to be shared for validating trust anchor) with those entities (ext auth svc and backend)

[guydc]

Option 1: it's possible (not 100% sure) that a server cert cannot always be used as a client cert, e.g. if it doesn't have the appropriate extended key usage TLS WWW client authentication. For example, see here.

Option 2 limits flexibility and option 3 creates a bit of duplication. I think that they're ok as mid-term mitigations.

I think that in one of the community meetings, we discussed the following option as well:

• Extend BackendTrafficPolicy to support a TLS section, like we do in ClientTrafficPolicy, which will also include client certs.
• Allow BTP to attach to K8s Services. Order of precedence for applying configuration is: xRoute > Gateway > Service.
• ExtAuth, RL, ExtProc can use a Service-level BTP to define TLS behaviors (and possibly other cluster-level settings [circuit breakers, timeouts, ... ]).
• xRoute/Gateway-attached BTP is used to set client certs for upstream backend connections.

[arkodg]

another option is defining the envoy certs within the EnvoyProxy API which is in line with the upstream discussion https://github.com/kubernetes-sigs/gateway-api/discussions/2743

[github-actions[bot]]

This issue has been automatically marked as stale because it has not had activity in the last 30 days.

[arkodg]

suggest waiting for upstream to align on naming https://github.com/kubernetes-sigs/gateway-api/pull/2910

[guydc]

suggest waiting for upstream to align on naming kubernetes-sigs/gateway-api#2910

With the merge of the above, should we proceed with for something like:

• BackendTLS.ClientCertificateRef for Client Certificate: #2984
• BackendTLS.Validation for TLS Params #2901

[arkodg]

Fixed with https://github.com/envoyproxy/gateway/pull/3218

[guydc]

Hi @arkodg . I think that #3218 only included TLS params, not client certs. I think that @alexwo intends to pick up client certs in the future. Should we keep this open for now?

[arkodg]

my bad, reopening this one

[alexwo]

/assign

[shawnh2]

closed in favor of https://github.com/envoyproxy/gateway/pull/3441