-
Notifications
You must be signed in to change notification settings - Fork 453
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
GEP: TLS from Gateway to Backend for ingress (backend TLS termination) #1897
Comments
@candita: The label(s) In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
/kind gep |
See discussion in #1067 |
/assign |
Note: this GEP is pulling TLS use cases from this earlier proposal - #1282 |
We merged the Provisional version of this, but we haven't delivered the GEP yet, so reopening. |
@davidhadas has a use-case where he'd like to be able to specify a list of exact-matched subjectNames, at least one of which must match when connecting to the backend. It's not clear whether the current API proposals support a list or only a single-element match. |
Will leave this open until the GEP goes to GA. /reopen |
@robscott: Reopened this issue. In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
@robscott to confirm my understanding of the GEP process, is GA considered |
We actually haven't had much experience yet with finalizing this state, but either one of those seems reasonable to me for now. |
The Kubernetes project currently lacks enough contributors to adequately respond to all issues. This bot triages un-triaged issues according to the following rules:
You can:
Please send feedback to sig-contributor-experience at kubernetes/community. /lifecycle stale |
Planning to start conformance testing soon. |
I'm thinking that we may want to narrow the scope of the title of this GEP to reflect the scope that BackendTLSPolicy launched with in v1.0. That policy is focused on verifying the certificates served by the backend. The other part of TLS from Gateway to Backend would be configuring a client cert that a Gateway should use to connect to a Backend. In my opinion, that's probably best accomplished with a separate GEP. If everyone's OK with that, I'll adjust the title of this GEP to reflect that narrower scope and create a new GEP issue to track configuring how the Gateway connects to backends. |
Was a new GEP for client certs ever filed? I'd be interested in it. In particular, if SPIFFE/SPIRE could be used as the client/remote certs. |
I would be also very interested to know what is the status of this? |
@albionb96 @kfox1111 the new GEP for client certs is https://gateway-api.sigs.k8s.io/geps/gep-91/ Not sure if this is what you're looking for, but
|
@candita thank you for your response. I did a quick research and came up with some results (please correct me if I am wrong): Number 1 (Client-Cert): will be addressed with this GEP: https://gateway-api.sigs.k8s.io/geps/gep-91/ Number 3 (Client-Cert): will be addressed with this GEP: https://gateway-api.sigs.k8s.io/geps/gep-1897/?h=1897+gep 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? 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! |
Yes. Although because of the crossover with Service Mesh's use of "mTLS", we've tended to be more specific about our language. But assuming you're meaning "mTLS" as "a TLS transaction where the client and server both validate each other's certificates" (and not "automatically provisioned and rotated invisibly by infrastructure TLS between a services", which is what Service Mesh contexts usually mean by "mTLS"), then yes, those GEPs should give that. Again, we have used the term "re-encrypt" in the past, but have found it can mean different things to different people, so we try to be more specific.
As of now, there are no plans to do identity forwarding. But it's certainly something we would consider if someone raised the request. |
The Kubernetes project currently lacks enough contributors to adequately respond to all issues. This bot triages un-triaged issues according to the following rules:
You can:
Please send feedback to sig-contributor-experience at kubernetes/community. /lifecycle stale |
/remove-lifecycle stale Definitely not stale, still being worked on. |
What would you like to be added:
Add a document which specifically addresses the topic of conveying HTTPS from the Gateway dataplane to the backend (backend TLS termination), and intends to satisfy the single use case “As a client implementation of Gateway API, I need to know how to connect to a backend pod that has its own certificate”. TLS configuration can be a nebulous topic, so in order to drive resolution this GEP focuses only on this single piece of functionality.
Given that the current ingress solution specifies edge TLS termination (from the edge to the gateway), and how to handle passthrough TLS (from the edge to the backend pod), this proposed ingress solution specifies backend TLS termination (from the gateway to the backend pod). As mentioned, this solution satisfies the use case in which the backend pod has its own certificate and the gateway client needs to know how to connect to the backend pod.
Why this is needed:
The document is very tightly scoped because we have tried and failed to address this well-known gap in the API specification. The lack of support for this fundamental concept is holding back Gateway API adoption by users that require a solution to the use case. One of the recurring themes that has held up the prior art has been interest related to service mesh and as such this proposal focuses only on the ingress use case to avoid contention there. Another reason for the tight scope is that we have been too focused on a generic representation of everything that TLS can do, which covers too much ground to address in a single GEP.
The text was updated successfully, but these errors were encountered: