Supporting wildcard domains for TLS: Kubernetes Ingress on GKE

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/v1beta1kind: Ingressmetadata:  annotations:    kubernetes.io/ingress.class: nginx    nginx.ingress.kubernetes.io/rewrite-target: /$1    cert-manager.io/cluster-issuer: letsencrypt-prod  name: my-ingressspec:  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.