https://rancher.com/ logo
Title
r

refined-analyst-8898

04/15/2023, 3:16 AM
I really wish there was a way to terminate TLS on the Rancher containers instead of an Ingress resource.
I want to access Rancher Manager privately with verifiable certs, not the dynamic certs Rancher issues to itself. I think I've exhausted all the alternatives looking for this: external TLS, source "secret", source "rancher", and source "letsEncrypt". All of these provide TLS, but none of them provide a verifiable cert terminating TLS on the pod itself.
r

rough-farmer-49135

04/17/2023, 12:32 PM
Is https://kubernetes.github.io/ingress-nginx/user-guide/tls/#ssl-passthrough something other than what you're looking for? My understanding is that for this sort of thing you need to look into the upstream documentation, as Rancher's fairly agnostic. Now, you may want to do that on a separate ingress controller instance, but it should be feasible.
r

refined-analyst-8898

04/17/2023, 1:16 PM
Thanks, @rough-farmer-49135. I want to configure the Rancher container with a private key and certificate so it can terminate TLS on the pod, not an Ingress or other external proxy. The Helm chart, if I understand it correctly, is opinionated on this point and insists on providing a "dynamic" TLS server certificate, but I want to bring my own certificate.
r

rough-farmer-49135

04/17/2023, 1:31 PM
I tend to have wildcard DNS in front of my cluster and separate pods by hostname. With that I'm fairly sure I got SSL directly to the pod (I was messing with it for a security application that wanted to do 2 way SSL between parts of it that it expected to use a load balancer for but I didn't have spare IPs and was trying to shoehorn through NGINX ingress controller and I did get it working while breaking everything else expecting plain text, but since it wasn't my app I'm not 100% sure).
I have also set up multiple ingress controllers (using taints & tolerations & node selectors to choose where the secondary ingress controllers lived) and used a different DNS subdomain on my load balancer in front of my cluster to shunt the things to the secondary set of ingress controllers. Not pretty or particularly elegant, but it worked for what I was trying.
Ah, I see what I missed. You want to change Rancher that way. That'd involve changing the Rancher container as far as I'm aware, so you'd need to do a build stage for a private Rancher container. If you're working air-gapped you could probably fit that in. Maybe something like setting up istio or another service mesh and setting it to encrypt all traffic between pods might be closer to what you're aiming for?
r

refined-analyst-8898

04/17/2023, 2:00 PM
I have a certificate I want to use with Rancher, and the cluster service TCP proxy is sufficient for load balancing across the pods that share that server certificate configuration. I will provide my own private point of entry to the cluster service, and so I do not need a gateway or ingress resource in this case.
r

rough-farmer-49135

04/17/2023, 2:02 PM
You should verify Rancher's ingress and make sure you've got whatever is there covered and at that point you could use a LoadBalancer while removing the ingress controller and have direct TCP access with that?
r

refined-analyst-8898

04/17/2023, 2:32 PM
Direct TCP / TLS-passthrough to the Rancher ClusterIP service is what I'm after, but I want to avoid an outward-facing exposure with a Gateway or Ingress. I have no problem providing my own private, L4 path to the ClusterIP, so I just need the Rancher pods to terminate TLS with the certificate that I provide in the form of a Kubernetes Secret of type
tls
, i.e., the type that is managed by Cert Manager. Thanks for helping me think through the options here.
r

rough-farmer-49135

04/17/2023, 2:33 PM
Good luck. I've about exhausted my ideas, hope one of them or something one jogged loose helps.
r

refined-analyst-8898

04/26/2023, 1:56 PM
Another alternative that Rancher doesn't seem to support yet is specifying the certificate issuer when TLS source is LetsEncrypt. Currently, Rancher insists on creating a LE issuer which can solve HTTP01 challenges only, but my goal is to terminate TLS for a private Rancher with a certificate I obtained through a DNS01 challenge, which does not require public internet ingress nor Kubernetes Ingress.