TLS Termination Policy

[danehans]

What would you like to be added:
As an application developer, I need the ability to specify a TLS termination policy for my HTTPRoute to specify how the associated connections should be handled by the Gateway.

Why is this needed:
I create HTTPRoutes routes foo, bar and baz (with TLS configured). I need tls connections for route foo to be:
client----(tls)----->gateway----(http)---->service
The tls connection is terminated at the gateway and an http connection is created to the service.

I need tls connections for route bar to be:
client----(tls)----->gateway----(tls-2)---->service
Where tls-2 is a new tls connection between gateway and service. Options should be provided for one and two-way authentication between gateway and service.

I need tls connections for route baz to be:
client----(tls)----->gateway----(tls)---->service
Where the client tls connection is not terminated at the gateway, but instead is passed through to the backend service.

Implementation References

• Contour's HTTPProxy
• Istio's Gateway
• OpenShift's Route

[danehans]

Can this be achieved using match/filter/action of a route? If so, how easy is the workflow understood by a user? Is this a gateway class, gateway or route setting?

[bowei]

In scenario 2, are you doing http routing before using TLS on the backside? This might be handled by saying that the Service app-protocol field can be used to determine whether or not TLS will be used on the Gateway/HTTPRoute => Service leg of the journey.

In scenario 3, what kind of routing are you expecting wrt to TLS? For example, this could just be TCP passed through OR is there some form of routing on the hostname that happens?

[jpeach]

/kind user-story

[hbagdi]

what kind of routing are you expecting wrt to TLS? For example, this could just be TCP passed through OR is there some form of routing on the hostname that happens?

I think both are valid use-cases.
See #81 (comment)

[danehans]

In scenario 2, are you doing http routing before using TLS on the backside?

@bowei I call scenario 2 "Reencrypt" in which the gateway terminates the client-side tls connection and creates a new tls connection to the backend service. The gateway would associate a ca bundle with the route to auth the backend service. PTAL at https://github.com/kubernetes-sigs/service-apis/pull/71/files#diff-c32a8ad2aa56de73b42e20d9e3cc82d8 for an example.

This might be handled by saying that the Service app-protocol field can be used to determine whether or not TLS will be used on the Gateway/HTTPRoute => Service leg of the journey.

Can you help me better understand "Service app-protocol field"? Are you referring to service.spec.ports[x].protocol? PTAL at #71 on my thoughts for implementation.

In scenario 3, what kind of routing are you expecting wrt to TLS? For example, this could just be TCP passed through OR is there some form of routing on the hostname that happens?

I call this scenario "Passthrough". Yes, the supported route type would be TCPRoute, which could forward to a backend Service or TCPSplit that would load balance across multiple backend services pending #57

[hbagdi]

Can you help me better understand "Service app-protocol field"?

He is referring to a new field that is coming in 1.18: kubernetes/enhancements#1422

[bowei]

Thanks for providing the link.

[danehans]

He is referring to a new field that is coming in 1.18: kubernetes/enhancements#1422

@bowei do we want to address this use case for pre 1.18 clusters that don't support the Service app-protocol field?

[robscott]

As a bit of a tangential update, that field did land in 1.18 but due to backwards compatibility requirements had to be feature gated - it won't be enabled by default until 1.19, so given the extended timeline it might be worth looking at potential solutions here as well. For reference, here's the PR updating the KEP to reflect that updated timeline: kubernetes/enhancements#1676

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

[hbagdi]

@danehans @bowei @jpeach @robscott With the current state of the API, is it safe to close this?

[hbagdi]

Considering this resolved.
Please re-open if otherwise.
/close.

[hbagdi]

/close

[k8s-ci-robot]

@hbagdi: Closing this issue.

In response to this:

/close

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.