Serving: Support wildcard certificate for Auto TLS feature

Created on 9 May 2019  路  3Comments  路  Source: knative/serving

In what area(s)?

/area networking

Describe the feature

Currently every time when creating a new Route/Knative Service, a new TLS certificate needs to be requested because the TLS certificate only supports the hosts of the Route. This is not efficient:

  1. It could take 3-5 minutes to get a certificate.
  2. It limits the number of Routes/Knative Services that could handle HTTPS connection because LetsEncrypt has the quota of issuing certificates, which is 50 per week.

As cert-manager can also issue wildcard certificate, it would be very nice to support wildcard certificates within Knative and reuse wildcard certificates across the Routes in a whole namespace or even the whole cluster.

Proposal

A separate controller could be built. It watches Namespace and requests wildcard certificate with the DNS Name format defined in config-network ConfigMap.

For example, for a DomainTemplate "{{.Name}}.{{.Namespace}}.{{.Domain}}", it could request a wildcard cert with DNS name *.{{.Namespace}}.{{.Domain}}.

If users define some specific format for DomainTemplate, e.g. {{.Name}}-{{.Namespace}}.{{.Domain}}, the wildcard certificate (*.{{.Domain}}) could be even shared within the whole cluster.

TLS certificates could be requested by reconciling Knative Certificate object.

Caveat

  1. We need to check the format of DomainTemplate as not every format works with this solution. Theoretically, the DomainTemplate could be arbitrary format, e.g. "{{.Namespace}}.{{.Name}}.{{.Domain}}". In this case, the namespace-level wildcard cert has no meaning as every time when a Route is created, a new cert is still needed.

  2. We also need to provide a knob to whitelist namespaces. And we probably don't need to request certs for some system namespaces (e.g. kube-system).

arenetworking kinfeature

Most helpful comment

thanks for writing this up! I think @rmoe would like to take this on

All 3 comments

/cc @mattmoor @tcnghia @greghaynes

Forgot to mention another related work item:
After we support wildcard certificate, Route controller should look for the wildcard certificate first, and fall back to the Route-level certificate if there is no available wildcard cert.

thanks for writing this up! I think @rmoe would like to take this on

Was this page helpful?
0 / 5 - 0 ratings