EKS: Avoid exposing port 80 via AWS NLB for Kong ingress controller

Hi folks I have the following data flow

client browser → AWS NLB → EKS kong ingress controller (exposed via Loadbalancer service of proxy)

I used helm charts to install Kong ingress controller in a new EKS cluster (this is the only ingress controller in that cluster)

When I deploy the Kong Ingress controller via helm I get two target groups created in AWS NLB one for port 80 and another for 443. My certificate is terminated on the NLB and I have the below annotation used in my helm values.yaml (proxy section)

annotations: {

  "service.beta.kubernetes.io/aws-load-balancer-internal": "true",

  "service.beta.kubernetes.io/aws-load-balancer-type": "nlb",

  "service.beta.kubernetes.io/aws-load-balancer-ssl-cert": "arn:aws:acm:us-east-1:XXXXXX",

  "service.beta.kubernetes.io/aws-load-balancer-backend-protocol": "http",

  "service.beta.kubernetes.io/aws-load-balancer-ssl-ports": "443"

}

This all works but it works for both http as well as https. I want to make it work for only https. How can I achieve the same

Any help is much appreciated.
@hbagdi tagging you as I see you actively helping others with similar issue. Hopefully you have time to assist

Are you sure you want to do this? You should be able to remove the HTTP listen by disabling it in the chart configuration. That’s a bit atypical, but it may be reasonable if you have full control over everything that will hit your endpoints.

For most configurations, I’d expect that you’d actually leave the HTTP listen in place to handle upgrading requests that initially come in over HTTP. You can set a route/Ingress’s protocols to [https] instead of the default [http,https] and it will respond to all HTTP requests that otherwise match with a redirect, using its https-redirect-status-code (default 426; you’ll probably want to change it to 301).

@traines

Thanks for responding. I think what you are suggesting is what is documented in this Kong documentation (if I understand it correctly) –

My problem statement is a bit different, I do not want to expose port 80 on the NLB side. My TLS (cert) terminates on the AWS NLB. So basically my data flow is as shown below

Client browser (https) ==> NLB(p443, cert term here) ==> Kong proxy (port 8000 – clear text)

I believe this is what I have to do:

Make the Kong proxy Service be of type NodePort (and not LoadBalancer)

Create the NLB outside of the Kong helm chart and expose port 443 outwards (to the client) and assign ACM cert to it so the TLS terminates on NLB, On the back-end I then need to create a Target Group that routes TCP traffic to Kong “proxy” service Nodeport (say 32080, which maps to 8000), so the data flow is going to be as shown below

Client browser (https) ==> NLB(p443, cert term here) ==> Kong proxy nodeport (port 32080 – clear text) ==> Kong proxy container port 8000 (clear text)

Let me know your thoughts.

Also since I have your attention can you also comment on another topic for which I need inputs from the community –

Kong Arch

Your response is much appreciated.

That sounds normal enough and doable–there may be some kinks to work out still but you’re on the right track. If you don’t have an HTTP-aware proxy at the edge to pass X-Forwarded-Proto info (I don’t believe the PROXY protocol has that level of info with a L4 edge LB), it may be the only option unless you want to set up a private certificate on Kong so that you can keep TLS end-to-end.