Interceptor Proxy - TLS On The Wire

[zorocloud]

Proposal

Currently the interceptor proxy does not support TLS on the wire for requests that it receives or forwards on to target services. In order to facilitate running the interceptor proxy in a secure cluster environment it should be able to serve all traffic over a TLS enabled server and be able to forward traffic on to destination services over a TLS connection.

Use-Case

Running the interceptor proxy in secured cluster environments where TLS on the wire is mandatory.

Is this a feature you are interested in implementing yourself?

Yes

Anything else?

No response

[JorTurFer]

This is an excellent idea, I like it!
Are you willing to contribute to this?
I think that we should allow to proxy the request, delegating the TLS to the backend. I guess that we could start a TLS port and just proxy the backend TLS, but maybe you have any other suggestion for it (I'm not an expert on reverse proxies written in go, so maybe I'm missing something xD)

[zorocloud]

Yes willing to contribute it @JorTurFer :)

I was thinking something along the lines of having the interceptor proxy terminate the initial TLS connection and establish a new one to the upstream when the request is ready to be passed on (upstream replicas available to serve the request). I can put a PR together and you could give your thoughts on whether it would be suitable?

[JorTurFer]

I was thinking something along the lines of having the interceptor proxy terminate the initial TLS connection and establish a new one to the upstream when the request is ready to be passed on (upstream replicas available to serve the request)

The problem in this case will be that the proxy won't be transparent. I mean, if your backend is serving its own TLS (instead of using the ingress as TLS end), you will be overriding it and the interceptor has to be aware of the cert to be served, which could make the process more complex. This could be feasible if you want to maintain the TLS between the ingress and the backend, because in that case the ingress is the TLS, but in the TLS end is your backend...

Is there any way to just proxy pass the request?

[zorocloud]

This could be feasible if you want to maintain the TLS between the ingress and the backend, because in that case the ingress is the TLS, but in the TLS end is your backend...

The scenario I had in mind was something similar to what I think you have described here....

Request -- TLS --> Ingress (terminate and re-establish) -- TLS --> Interceptor Proxy (terminate and re-establish) -- TLS --> Destination service

It would still be transparent from an end user perspective as they are still only terminating TLS with the Ingress and have no awareness of any further connections initiated upstream.

Is there any way to just proxy pass the request?

I think you would still need the interceptor proxy to have a TLS server to terminate the request so you could establish the destination to forward it on to but I can have a quick look into it.

[JorTurFer]

Request -- TLS --> Ingress (terminate and re-establish) -- TLS --> Interceptor Proxy (terminate and re-establish) -- TLS --> Destination service

I think that this can be good enough, but it requires that the interceptor manages somehow the certificates (its own and also trust on backend certs). I guess that for the backend certs we could go just skipping the cert validation (despite fixing this would be nice too), but we need to solve the cert management on interceptor side.
@tomkerkhove , could you share your thoughts?

IIRC, some ingress controllers (such as nginx) don't support custom CAs when they call to HTTPS backends.

[zorocloud]

PR raised. Let me know your thoughts :)

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 7 days if no further activity occurs. Thank you for your contributions.