Cannot get an HTTPS -> HTTPS Load-Balancer

[Seb-C]

I am trying to setup a basic Load-Balancer using kubernetes. I tried everything and looked at every configuration and even in the source code, but I cannot figure out how to achieve the configuration I want.

What I want to achieve is this:

HTTP on port 80 -> HTTP on port 80
HTTPS on port 443 -> HTTPS on port 443

Note that this is not a passthrough. The load-Balancer unencrypts the request using the certificate in my account, then re-sends it via HTTPS to my pod using a self-signed certificate.

When I set this up manually via the interface, it works well. However it does not seem to be possible using Kubernetes. The kubernetes service always create this setup:

HTTP on port 80 -> HTTP on port 80
HTTPS on port 443 -> HTTP on port 443

So it tries to do HTTP on my port 443 and it does not work (note: In this example I redacted the real target port so it’s easier to understand).

This seems to be because of this part of the code:

digitalocean-cloud-controller-manager/cloud-controller-manager/do/loadbalancers.go

Line 862 in e4fb291

forwardingRule.TargetProtocol = protocolHTTP

Here is my current Kubernetes service for reference:

apiVersion: v1
kind: Service
metadata:
  name: server
  annotations:
      service.beta.kubernetes.io/do-loadbalancer-name: "xxx"
      service.beta.kubernetes.io/do-loadbalancer-size-slug: "lb-small"
      service.beta.kubernetes.io/do-loadbalancer-protocol: "http"
      service.beta.kubernetes.io/do-loadbalancer-http-ports: "80"
      service.beta.kubernetes.io/do-loadbalancer-tls-ports: "443"
      service.beta.kubernetes.io/do-loadbalancer-tls-passthrough: "true"
      service.beta.kubernetes.io/do-loadbalancer-redirect-http-to-https: "true"
      service.beta.kubernetes.io/do-loadbalancer-enable-proxy-protocol: "true"
      service.beta.kubernetes.io/do-loadbalancer-certificate-id: "xxx"
      service.beta.kubernetes.io/do-loadbalancer-algorithm: "least_connections"
      service.beta.kubernetes.io/do-loadbalancer-healthcheck-port: "443"
      service.beta.kubernetes.io/do-loadbalancer-healthcheck-protocol: "https"
      service.beta.kubernetes.io/do-loadbalancer-healthcheck-path: "/api/health-check"
      service.beta.kubernetes.io/do-loadbalancer-healthcheck-check-interval-seconds: "5"
      service.beta.kubernetes.io/do-loadbalancer-healthcheck-response-timeout-seconds: "5"
      service.beta.kubernetes.io/do-loadbalancer-healthcheck-unhealthy-threshold: "3"
      service.beta.kubernetes.io/do-loadbalancer-healthcheck-healthy-threshold: "2"
spec:
  type: LoadBalancer
  selector:
    app: server
  ports:
    - name: http
      protocol: TCP
      port: 80
      targetPort: 80
    - name: https
      protocol: TCP
      port: 443
      targetPort: 443

[timoreimann]

Relaying HTTPS all the way through to the endpoint with termination is indeed not possible right now. See also the implications described by me in #351 (comment).

We originally used #351 to track work on supporting the feature in question. That ticket is sort of overloaded with another, more specific request, however, so let's use this ticket instead.

[Seb-C]

OK, Thanks. Can I expect this to be supported any time soon?

[timoreimann]

@Seb-C there's no specific timeline yet, though overall the request should be fairly simple to implement by introducing yet another annotation.

To better understand your use case, could you elaborate why HTTPS-to-HTTP isn't a good option for you? (Note that the target/backend part of the LB request runs through the VPC, so no man-in-the-middle sitting on the public Internet should be able to sniff on your traffic.)

[Seb-C]

I have do doubt that DO's infrastructure is as reliable as possible, but I feel better giving my users more security when possible, that is the only reason. You never know what could happen.

To be honest one of the main selling points for the LB to me was that I did not want to manage the certificate myself (I can probably handle the balancing in my cluster for now anyway), but now I just discovered that there is a certbot/dns-digitalocean script and docker image, so I am currently reconsidering my choice.

I think this is still a valid issue even if I may not need it anymore.

[timoreimann]

@Seb-C thanks for elaborating. I believe your point is quite valid.

Regardless or not whether you might still need / want HTTPS-to-HTTPS routing, I'll keep the issue open since a few other folks have asked for it as well.

Appreciate the feedback.

[adrian-dinu]

@timoreimann Would love to see this as well, compliance rules do dictate we use SSL inside our infrastructure, as well from requests coming from outside.