0

We're currently trying to deploy Kong in a GKE cluster and the goal is to delegate the certificate management to Google's Load Balancer (the SSL termination should be made here).

The problem we faced is that all Google's documentation is focus on deploying some service and use their exclusive Load Balancer that connects directly to the Ingress declared.

The configuration which currently works (without Kong) is the following:

# values.yml (from Service X inside GKE, using Helm)
...
ingress:
  enabled: true
  hostname: example.com
  annotations:
    kubernetes.io/ingress.class: gce
    kubernetes.io/ingress.allow-http: "false"
    kubernetes.io/ingress.global-static-ip-name: example-static-ip
    ingress.gcp.kubernetes.io/pre-shared-cert: example-cert
...

However, when we change gce for kong as the ingress.class, all other annotations don't continue to work. This is expected, as now Kong's proxy is the one being the Load Balancer and should be the one that tells Google's LB how to generate itself.

According to this documentation, it should be fairly simple to add those annotations to Kong proxy service.

Based on this chain of events:

  • K8s Ingress creates Kong proxy service
  • Kong proxy service generates Google's LB

The configuration to customize the LB should be made inside Kong's service (as I understand):

# values.yml (Kong, using Helm)
...
proxy:
  type: LoadBalancer
  annotations: {} <-- Here
  http:
    ...
  tls:
    ...
...

However, for GCP there are only a few according to the docs, and none of them have the desire effect (cannot set certificate to use, define which type of LB to create, etc.)

All things into account, is there any way to achieve our main goal which would be:

"Deploy Kong API Gateway through Helm inside GKE and delegate SSL termination to custom Google's LB."

manuelnucci
  • 163
  • 2
  • 12

1 Answers1

1

TL;DR

Unfortunately there is no possibility to use Google Managed Certificates with Kong Ingress.

To be exact Google Managed Certificates in GKE can be used only with:

  • Ingress for External HTTP(S) Load Balancing

As pointed by documentation:

Note: This feature is only available with Ingress for External HTTP(S) Load Balancing.

-- Cloud.google.com: Kubernetes Engine: Docs: How to: Managed certs

Explanation

According to the documentation (slightly modified):

When you create an Ingress object with below class:

  • kubernetes.io/ingress.class: gce

the GKE Ingress controller creates a Google Cloud HTTP(S) Load Balancer and configures it according to the information in the Ingress and its associated Services.

-- Cloud.google.com: Kubernetes Engine: Ingress: Ingress for external and internal traffic

Using different Ingress controllers like (nginx-ingress, traefik, kong) require you to use Service of type LoadBalancer.

Using above Service in GKE will automatically create External TCP/UDP Network Load Balancer (L4) pointing to your Ingress controller. From this point the traffic will be redirected to specific services based on the Ingress resource with appropriate ingress.class.

A tip!

You can see in the helm chart of Kong that it's using the same way!

  • helm install kong/kong kong-ingress --dry-run --debug

To have the secure connection between the client and kong you will need to either:

Side note: In both ways the SSL termination will happen at the Ingress controller.

Answering the part of the question:

The configuration to customize the LB should be made inside Kong's service (as I understand):

# values.yml (Kong, using Helm)
...
proxy:
  type: LoadBalancer
  annotations: {} <-- Here
...

However, for GCP there are only a few according to the docs, and none of them have the desire effect (cannot set certificate to use, define which type of LB to create, etc.)

As said earlier Service of type LoadBalancer in GKE will configure L4 TCP/UDP LoadBalancer which is not designed to be responsible for handling SSL traffic (SSL termination).

Additional resources:

Dawid Kruk
  • 8,982
  • 2
  • 22
  • 45
  • Great, thank you for clarifying a lot of aspects. The last detail that I would like to know is, when you say to _"use certificates provisioned in other way"_, GCP could be an option. However, as we realized, none of them can be downloaded and then injected as secrets (despite other limitations that they have). So, in conclusion, the certs should be issued by someone else, am I correct? – manuelnucci Nov 18 '20 at 16:49
  • 1
    Yes, you are correct. One of the options could be: https://letsencrypt.org/ . I added the `cert-manager` as a viable solution. It can use `lets-encrypt` for provisioning the certificates. – Dawid Kruk Nov 18 '20 at 17:11