Supporting wildcard domains for TLS: Kubernetes Ingress on GKE

Question

I'm working on an application that deploys kubernetes resources dynamically, and I'd like to be able to provision a shared SSL certificate for all of them. At any given time, all of the services have the path *.*.*.example.com .

I've heard that cert-manager will provision/re-provision certs automatically, but I don't necessarily need auto-provisioning if its too much overhead. The solution also needs to be able to handle these nested url subdomains.

Any thoughts on the easiest way to do this?

Answer 1

Have a look at nginx-ingress , which is a Kubernetes Ingress Controller that essentially makes it possible to run Nginx reverse proxy/web server/load balancer on Kubernetes.

nginx-ingress is built around the Ingress resource. It will watch Ingress objects and manage nginx configuration in config maps. You can define powerful traffic routing rules, caching, url rewriting, and a lot more via the Kubernetes Ingress resource rules and nginx specific annotations .

Here's an example of an Ingress with some routing. There's a lot more you can do with this, and it does support wildcard domain routing .

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  annotations:
    kubernetes.io/ingress.class: nginx
    nginx.ingress.kubernetes.io/rewrite-target: /$1
    cert-manager.io/cluster-issuer: letsencrypt-prod
  name: my-ingress
spec:
  rules:
  - host: app1.domain.com
    http:
      paths:
      - backend:
          serviceName: app1-service
          servicePort: http
        path: /(.*)

  - host: app2.sub.domain.com
    http:
      paths:
      - backend:
          serviceName: app2-service
          servicePort: http
        path: /(.*)
  tls:
  - hosts:
    - app1.domain.com
    secretName: app1.domain.com-tls-secret
  - hosts:
    - app2.sub.domain.com
    secretName: app2.sub.domain.com-tls-secret

The annotations section is really important. Above indicates that nginx-ingress should manage this Ingress definition. This annotations section allows to specify additional nginx configuration, in the above example it specifies a url rewrite target that can be used to rewrite urls in the rule section.

See this community post for installing nginx-ingress on GKE.

You'll notice the annotations also have a cert manager specific annotation which, if installed will instruct cert manager to issue certificates based on the hosts and secrets defined under the tls section.

Using cert-manager in combination with nginx-ingress, which isn't that complicated, you can set up automatic certificate creation/renewals.

It's hard to know the exact nature of your setup with deploying dynamic applications. But some possible ways to achieve the configuration are:

• Have each app define it's own Ingress with it's own routing rules and TLS configuration, which gets installed/updated each time your the application is deployed
• Have an Ingress per domain/subdomain. You could then specify a wild card subdomain and tls section with routing rules for that subdomain
• Or possibly you could have one uber Ingress which handles all domains and routing.

The more fine grained the more control, but a lot more moving parts. I don't see this as a problem. For the last two options, it really depends on the nature of your dynamic application deployments.