GEP: TLS from Gateway to Backend for ingress (backend TLS termination)

[candita]

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.

[k8s-ci-robot]

@candita: The label(s) /label kind/gep cannot be applied. These labels are supported: api-review, tide/merge-method-merge, tide/merge-method-rebase, tide/merge-method-squash, team/katacoda, refactor. Is this label configured under labels -> additional_labels or labels -> restricted_labels in plugin.yaml?

In response to this:

/label kind/gep

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]

/kind gep
/remove-kind feature

[candita]

See discussion in #1067

[candita]

/assign

[dprotaso]

Note: this GEP is pulling TLS use cases from this earlier proposal - #1282

[youngnick]

We merged the Provisional version of this, but we haven't delivered the GEP yet, so reopening.

[evankanderson]

@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.

[robscott]

Will leave this open until the GEP goes to GA.

/reopen

[k8s-ci-robot]

@robscott: Reopened this issue.

In response to this:

Will leave this open until the GEP goes to GA.

/reopen

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.

[danehans]

Will leave this open until the GEP goes to GA.

@robscott to confirm my understanding of the GEP process, is GA considered standard or completed status?

[youngnick]

We actually haven't had much experience yet with finalizing this state, but either one of those seems reasonable to me for now.

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[candita]

Planning to start conformance testing soon.
/remove-lifecycle stale

[robscott]

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.

[kfox1111]

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.

[albionb96]

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?

[candita]

@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

This GEP proposes a way to validate the TLS certificate presented by the frontend client to the server (Gateway Listener in this case) during a TLS Handshake Protocol.

[albionb96]

@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 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!

[youngnick]

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

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.

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?

As of now, there are no plans to do identity forwarding. But it's certainly something we would consider if someone raised the request.

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[youngnick]

/remove-lifecycle stale

Definitely not stale, still being worked on.