Ssl-policy annotations with AWS NLB in Kong Ingress Controller

Kubernetes
#1

I was not able to find a way to pass a annotation for kong ingress to change the default ssl policy for the listener, by default is using the ELBSecurityPolicy-2016-08 value, described as default at AWS’s documentation Create an HTTPS listener for your Application Load Balancer - Elastic Load Balancing

I’ve found that kubernetes-sig has some implementation for that using the annotation ssl-policy Annotations - AWS LoadBalancer Controller

Has kong some kind of annotation to tell AWS to change the ssl-policy?

#2

Were you actually able to create an ALB? As best I know, the AWS cloud provider only creates ALBs if you’re using their ingress controller. Services that request a LoadBalancer directly (such as the Kong proxy Service) are limited to L4 NLBs, and those annotations won’t apply.

For Kong, that type of configuration is set via various TLS configuration settings in kong.conf or equivalent environment variables, not per-Ingress.

#3

Sorry if my text was confusing, as it stands in the tittle what was created was a NLB (Network Load Balancer), my point was that the listener that AWS creates when I apply the manifest, use the default TLS configuration, and since I configuared the certificate in use by the listeners using an annotation (service.beta.kubernetes.io/aws-load-balancer-ssl-cert) I thought that the place to configure the protocol of the listeners was the same place.

I made a test changing the listeners ssl-policy from AWS according to their documentation and no weak cypher was used in the communication, but I had to do it manually, and was not able to found a place to do it from the manifest itself.

As much as I understand, changing values in kong.conf will not affect the NLB’s listeners configurations, because the problem I found is the use of a weak algorithm into the listener itself.

#4

The title and body were referencing different things and I looked more at the latter. Annotations - AWS LoadBalancer Controller is listing annotations that can be applied to an Ingress resource when using AWS’s controller, which spawns ALBs and configures them per-Ingress.

When you use our controller, any AWS LB configuration is instead set at the Service level, on the Service that requests a LoadBalancer for our proxy. If you’re using an NLB that handles TLS termination (the manual change to AWS configuration making a difference implies you are), the service.beta.kubernetes.io/aws-load-balancer-ssl-negotiation-policy from Annotations - AWS LoadBalancer Controller should be the equivalent Service-level annotation.

If you’re using an NLB that doesn’t terminate TLS, Kong is the first TLS-capable hop the client would hit, and that’s when the kong.conf settings would apply.

#5

Right,I’ve the problem when I use the NLB that handles TLS termination, the annotation doesn’t have effect.

#6

I used to have similar problems with our setup. In the end I found it a lot easier to take the NLB out of the equation and let Kong do the TLS termination. It has the added benefit that you can do all certificate management within Kubernetes as well which is fully automated with Let’s Encrypt without any DNS records hassle and such. It’s really quite wonderful :slight_smile:

I found the setup of cert-manager is really surprisingly straightforward. And the Kong part is documented here in great detail: Using cert-manager for automated TLS certificate - v1.2.x | Kong - Open-Source API Management and Microservice Management from there you can also find links to the cert-manager setup instructions.

#7

If the Service annotation isn’t working, check with AWS support. We don’t have any view into the code EKS uses to provision an LB according to the annotations on a Service, so while we can suggest the annotation that looks correct, we can’t diagnose issues where the provisioned LB doesn’t actually honor that request.

© 2019 Kong Inc.    Terms  •  Privacy  •  FAQ