-
Notifications
You must be signed in to change notification settings - Fork 17
Load balancer TLS termination [Reverted] #144
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
If TLS is terminated by an ALB, the service port 80 routes traffic without redirecting to HTTPS and the HTTPS port presents an error since it's pointing to another HTTPS port of the node. This change allows the load balancer to expose only port 443 externally which routes to the HTTP port of the coderd pod.
|
This pull request has been linked to Clubhouse Story #15687: Support TLS termination at the Load Balancer. |
Emyrk
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't have much context on this, but it seems reasonable.
| # coderd.httpsToHttp -- eliminates the external http port and routes traffic from | ||
| # the external https port to the internal http port. Useful for when the load balancer | ||
| # performs TLS termination (like Amazon's ACM) | ||
| httpsToHttp: false |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've done a little bit of reading (How do I terminate HTTPS traffic on Amazon EKS workloads with ACM?
) but am by no means an expert on AWS.
It seems unusual to me that we'd be using a LoadBalancer spec when a frontend device is performing termination for us, and instead I'd have expected that we'd use an Ingress definition to do this? A Kubernetes LoadBalancer would be more like an Layer 3 (Network Load Balancer) and a Service with Ingress would be more like a Layer 7 device (Application Load Balancer)
Alternatively, is there a way to configure things manually so that we expose coderd as a ServiceIP (on the internal VPC network) and then manage the NLB/ALB outside of our Kube specs? Adding stuff to our Helm chart, especially in the absence of tests, increases complexity, so my preference is always to keep one-off customizations like this out of there, unless this is a very general thing with all of the clouds...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It seems like an alternative to this implementation would be to make the full service spec configurable as users want, instead of using conditionals based on this httpsToHttp setting
If TLS is terminated by an ALB, the service port 80 routes traffic without redirecting
to HTTPS and the HTTPS port presents an error since it's pointing to another HTTPS
port of the node.
This change allows the load balancer to expose only port 443 externally which routes to
the HTTP port of the coderd pod.