Per-backend Mutual TLS to the backend

[howardjohn]

What would you like to be added:

A way to configure mTLS, from gateway to backend, on a per-backend basis.

Why this is needed:

Today, we have this on Gateway. This does not align with how any users of projects I am involved in want to use mTLS. Rather, they have per-backend mTLS key/certs. (A gateway-level policy would be more like what mesh mTLS solves, which users solve with a mesh that is orthogonal to the Gateway).

For example, they have credentials to access some external database, etc.

I would like a way to do mTLS on a per-Backend basis. Presumably this would be set in BackendTLSPolicy.

[youngnick]

To be clear, you want a way to supply a client certificate for the connection from a Gateway to a backend, on a per-backend basis?

One of the reasons I resisted this before is that, as I said earlier, to me, BackendTLSPolicy belongs to the entity who controls the Service, and so putting the client certificate on there does nothing to meet the assumption that the client and the server are controlled by different parties who get their own certs out of band. It effectively means that the mTLS in this case is only used for the Record protocol, the Handshake part of mTLS is meaningless, as both keypairs are supplied by the same party (the owner of the BackendTLSPolicy).

Is that sufficient for mTLS use cases? It doesn't seem it to me, but I'm interested to hear more.

[snorwin]

In setups where a Gateway is shared across multiple applications and where the application developers are responsible for issuing client certificates (where a client certificate serves a role similar to a auth token rather than representing an identity), it may be necessary to support multiple client certificates for a single Gateway. However, I agree with @youngnick that configuring them within the BackendTLSPolicy might not be the right approach.

[howardjohn]

One of the reasons I resisted this before is that, as I said earlier, to me, BackendTLSPolicy belongs to the entity who controls the Service, and so putting the client certificate on there does nothing to meet the assumption that the client and the server are controlled by different parties who get their own certs out of band. It effectively means that the mTLS in this case is only used for the Record protocol, the Handshake part of mTLS is meaningless, as both keypairs are supplied by the same party (the owner of the BackendTLSPolicy).

I disagree with this, now with the recent (some still in flight) changes are BTLSPolicy, particular the work around consumer-side overrides which means the info is put solely in the context of the consumer not the Service producer.

Regardless of intent of the API, its incorrect that both keypairs are provided by the same party. The keypairs used on the server are entirely outside of the scope of Gateway API and up to the application. For example, if I create a BackendTLSPolicy to do mTLS to google.com, I am definitely not picking their keypairs. There are the client key/cert, and the server ca cert. This is equivilent to curl --key key --cert cert --cacert cacert.