Path only rules ingress resources and ssl termination

Kubernetes
1

Hi,
we are using kong-ingress-controller:0.9.1, kong:2.0, traffic is balanced from external haproxy to Kong ingress controllers. Is there a way to use ingress resources with path only rules and still be able terminate ssl in Kong ingress controller for specified default host (api.test.dev for example) ?

If we create kubernetes ingress resource with host and tls, ssl is terminated in Kong ingress controller and route is working.

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: test
  namespace: test
  annotations:
    kubernetes.io/ingress.class: kong
    konghq.com/strip-path: "false"
    konghq.com/preserve-host: "false"
spec:
  rules:
    - host: api.test.dev
      http:
        paths:
        - path: /test/v1
          backend:
            serviceName: test-service
            servicePort: 80
  tls:
    - hosts:
      - api.test.dev
      secretName: test-dev-tls-secret

But if we create ingress resource with path only rule, route is not matched and response come from default host with generated certificate.

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: test
  namespace: test
  annotations:
    kubernetes.io/ingress.class: kong
    konghq.com/strip-path: "false"
    konghq.com/preserve-host: "false"
spec:
  rules:
    - http:
        paths:
        - path: /test/v1
          backend:
            serviceName: test-service
            servicePort: 80

I’m asking this because I’m trying to solve communication among services in cluster through Kong ingress controller only and cant find solution. What is best practice for use Kong ingress controller for communication among services internally in cluster. Should we use external load balancer address or can we use internal kong-proxy service created by deploy?

Thanks for advice.
PS

2

I don’t think so, no–it’s kinda theoretically possible but it’d be hacky.

When using the controller, certificate/SNI configuration is added to Kong based on the presence of TLS rules in the Ingress resource, and those require hostnames as part of the TLS spec. If none is present, no certificate is added, and you see the fallback to the default certificate you described.

While Kong supports decoupling certificates from individual routes, the Ingress spec doesn’t really (I could be wrong–I’m not sure if you can perhaps configure an Ingress with path-only rules and a TLS section that includes the hostnames and certificates; it may be worth trying that). There are a couple of alternatives:

  • Mount a certificate on the container filesystem and configure it as the default proxy certificate. That certificate is a auto-generated self-signed certificate if you configure nothing, but you can instead configure a pre-generated certificate whose SANs cover whatever hostnames you’d like to use with the path-only routes.
  • Manually add the certificate/SNI configuration you need via the admin API. This is only an option if you’re using a database, but if you do, you can create a certificate/SNI independent of the controller and Kong will serve it when it sees a TLS handshake with a matching hostname.

I’m assuming the end-goal here is probably to handle wildcard certificates better, which the Ingress spec doesn’t currently handle. However, https://github.com/kubernetes/kubernetes/issues/41881 indicates that will be coming soon, and while I can’t say exactly what our support for that would look like, it shouldn’t be too much work to add it once there’s support in the K8S API, as we already support wildcard hostnames at the route level. That won’t help for truly path-only routes, but I’m guessing that’s not the true goal here–you presumably have some set of known hostnames (which may be wildcards) because some have to be present on the certificates for TLS negotiation to work.

3

Kong has to load the certificate and will match using SNI based on the Host of the request, but if this route doesn’t load the cert another one would need to.

The TLS part of the Ingress spec tells Kong to load the cert. It doesn’t necessarily need to be on this route from my experience, but Kong must have the cert loaded somewhere else otherwise it has no cert to match.