General TLS status and roadmap

[albionb96]

Sorry, but I was trying in the last couple of days to understand what gatewayAPI offers in this regard and what is expected to be implemented.

After my research I came up with some result (and please correct me if I am wrong). I just wanted to know if I got it correct and also had two questions which I will address at the end:

The direction number 1 from the picture (Client-Cert): will be addressed with this GEP: https://gateway-api.sigs.k8s.io/geps/gep-91/
Number 2 (Server-Cert): Is already implemented and well-known where the Gateway API sends its cert to the Client for verification.

Number 3 (Client-Cert): will be addressed with this GEP: https://gateway-api.sigs.k8s.io/geps/gep-1897/?h=1897+gep
Number 4 (Server-Cert): Is addressed in the experimental channel with backendTLSPolicy: https://gateway-api.sigs.k8s.io/api-types/backendtlspolicy/

First question: If all of these GEPs are implemented would we then be able to achieve the "re-encrpyt" mode, with mutual authentication on both sides backend and frontend?
e.g.
FrontendClient<-mTLS->GatewayAPI<-mTLS->BackendService

or did I get it totally wrong and mutual authentication on both ends, (backend and frontend), or only one end and also re-encrypt is not planed at all?

Second question: even if I got everything correct and we will have re-encrypt with mutual authentication on both ends, how will be the identity of the client forwarded to the backend, because for me the frontendValdiation looks like a check up on the caCertificateRefs and that's it, the new connection from gateway API to backend won't know anything about the client or the requestor, right?

For example when using an envoy proxy it is possible to forward the identity of the requestor (frontendclient), using the XFCC-Header, is something like this possible in gatewayAPI also, or is this planned to happen somehow in the future?

Thank you very much in advance!

[candita]

Hi @albionb96,

These are good questions. The way that we describe and document TLS in Gateway API could use a glossary section, and you can find one proposed in https://gateway-api.sigs.k8s.io/geps/gep-2907. Also check out https://gateway-api.sigs.k8s.io/guides/tls/ and see if that helps. In many of our GEPs we do not explicitly mention mTLS because it has two different contexts - service mesh and service ingress. Please let us know the context of your question.

Also - re-encrypt is a term that leads to misunderstandings based on context. However, in the case of HTTPRoute, the use of both Terminate TLS mode and BackendTLSPolicy is supported. Using these together provides what is commonly known as a connection that is terminated and then re-encrypted at the Gateway.

This is how the certificates from your diagram are currently implemented:

1 Listener.TLS.FrontendValidation (GEP-91, to be experimental in v1.1)
2 Terminate TLS mode on Listener (standard)
3 not available
4 BackendTLSPolicy (GEP-1897, still experimental in v1.1)

There is also passthrough TLS, which bypasses the gateway so that the authentication is between frontend and backend.

Regarding your question:

the new connection from gateway API to backend won't know anything about the client or the requestor, right?
the client is the gateway.

You can check out another document which is a list of all TLS use cases that we've considered so far. If your use case isn't on it, you can propose a new use case.
https://docs.google.com/document/d/17sctu2uMJtHmJTGtBi_awGB0YzoCLodtR6rUNmKMCs8/edit#heading=h.cxuq8vo8pcxm

[albionb96]

Thank you very much for your response @candita!

I know that mTLS has some very narrow meaning in the service mesh, but what I meant was the normal mutual authentication server-client. Let's exclude the service mesh from this discussion entirely.

Ok that means that I got it mainly right when it comes to the status of the TLS implementation in gateway API. Beside the part that I thought that Number 4 is already supported with the BackendTLSPolicy based on this information: https://gateway-api.sigs.k8s.io/api-types/backendtlspolicy/ . I am not too familiar with the definitions used in this repo but I thought that there is no open GEP regarding this part anymore.

Regarding number 3, when you say "not available" does it also mean that there are no plans to implement it. Which also means that there won't be any possibility to have mutual authentication between gateway and the backend, it will be only one way (only the backend will sent its certificate and no certificate will be sent to the backend from the gateway)?

Regarding your question:

the new connection from gateway API to backend won't know anything about the client or the requestor, right?
the client is the gateway.

I know that the client in this case would be the gateway in order to have the mutual authentication established in the backend, but what I meant is that some solutions offer the possibility to forward some specific details of the "original" client to the backend, it can be some kind of identifier, in some cases it might be the original requestor's/client's certificate itself. This can be sometimes a legal requirement, as it is for example the case with the GDPR of EU.

Envoy for example offers something like this and forwards these information using the HTTP-forward headers:

[youngnick]

We have talked about how to implement Gateway -> Backend client certificate passing (where the Gateway has a client certificate and passes it to the backends as part of proxying traffic), but haven't landed on the correct place to put it yet.

So "not available" means currently not available, not will never be available. Unfortunately it's one item on a long list of things. As always, PRs and help welcomed!