Enabling auto-TLS certs
The following must be installed on your Knative cluster:
A Networking layer such as Kourier, Istio with SDS v1.3 or higher, or Contour v1.1 or higher. See or Istio with SDS, version 1.3 or higher.
.
Your Knative cluster must be configured to use a custom domain.
Your DNS provider must be setup and configured to your domain.
If you want to use HTTP-01 challenge, you need to configure your custom domain to map to the IP of ingress. You can achieve this by adding a DNS A record to map the domain to the IP according to the instructions of your DNS provider.
Knative supports the following Auto TLS modes:
Using DNS-01 challenge
In this mode, your cluster needs to be able to talk to your DNS server to verify the ownership of your domain.
Provision Certificate per namespace is supported when using DNS-01 challenge mode.
- This is the recommended mode for faster certificate provision.
- In this mode, a single Certificate will be provisioned per namespace and is reused across the Knative Services within the same namespace.
Provision Certificate per Knative Service is supported when using DNS-01 challenge mode.
- This is the recommended mode for better certificate isolation between Knative Services.
- In this mode, a Certificate will be provisioned for each Knative Service.
- The TLS effective time is longer as it needs Certificate provision for each Knative Service creation.
Using HTTP-01 challenge
- In this type, your cluster does not need to be able to talk to your DNS server. You must map your domain to the IP of the cluser ingress.
- When using HTTP-01 challenge, a certificate will be provisioned per Knative Service.
- HTTP-01 does not support provisioning a certificate per namespace.
Create and add the configuration file to your Knative cluster to define who issues the TLS certificates, how requests are validated, and which DNS provider validates those requests.
ClusterIssuer for DNS-01 challenge: use the cert-manager reference to determine how to configure your
ClusterIssuer
file.- See the generic
- Also see the DNS01 example
For example, the following
ClusterIssuer
file namedletsencrypt-issuer
is configured for the Let’s Encrypt CA and Google Cloud DNS. The Let’s Encrypt account info, requiredDNS-01
challenge type, and Cloud DNS provider info is defined underspec
.ClusterIssuer for HTTP-01 challenge
To apply the ClusterIssuer for HTTP01 challenge:
-
apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
spec:
acme:
privateKeySecretRef:
name: letsencrypt
server: https://acme-v02.api.letsencrypt.org/directory
solvers:
- http01:
ingress:
class: istio
Apply the YAML file by running the command:
kubectl apply -f <filename>.yaml
Where
<filename>
is the name of the file you created in the previous step.
-
Ensure that the ClusterIssuer is created successfully:
kubectl get clusterissuer <cluster-issuer-name> -o yaml
Result: The
Status.Conditions
should includeReady=True
.
If you choose to use DNS-01 challenge, configure which DNS provider is used to validate the DNS-01 challenge requests.
Instructions about configuring cert-manager, for all the supported DNS providers, are provided in .
Note that DNS-01 challenges can be used to either validate an individual domain name or to validate an entire namespace using a wildcard certificate like *.my-ns.example.com
.
Install net-certmanager-controller deployment
Determine if
net-certmanager-controller
is already installed by running the following command:kubectl get deployment net-certmanager-controller -n knative-serving
If
net-certmanager-controller
is not found, run the following command:kubectl apply -f https://github.com/knative/net-certmanager/releases/download/knative-v1.5.0/release.yaml
Warning
Provisioning a certificate per namespace only works with DNS-01 challenge. This component cannot be used with HTTP-01 challenge.
The per-namespace certificate manager uses namespace labels to select which namespaces should have a certificate applied. For more details on namespace selectors, see .
Prior to release 1.0, the fixed label networking.knative.dev/disableWildcardCert: true
was used to disable certificate generation for a namespace. In 1.0 and later, other labels such as kubernetes.io/metadata.name
may be used to select or restrict namespaces.
To enable certificates for all namespaces except those with the networking.knative.dev/disableWildcardCert: true
label, use the following command:
This selects all namespaces where the label value is not in the set "true"
.
Configure config-certmanager ConfigMap
Update your in the namespace to reference your new ClusterIssuer
.
Run the following command to edit your
config-certmanager
ConfigMap:kubectl edit configmap config-certmanager -n knative-serving
Add the
issuerRef
within thedata
section:apiVersion: v1
kind: ConfigMap
metadata:
name: config-certmanager
namespace: knative-serving
labels:
networking.knative.dev/certificate-provider: cert-manager
data:
issuerRef: |
kind: ClusterIssuer
name: letsencrypt-http01-issuer
Ensure that the file was updated successfully:
kubectl get configmap config-certmanager -n knative-serving -o yaml
Update the config-network ConfigMap in the knative-serving
namespace to enable auto-tls
and specify how HTTP requests are handled:
Run the following command to edit your
config-network
ConfigMap:kubectl edit configmap config-network -n knative-serving
Add the
auto-tls: Enabled
attribute under thedata
section:apiVersion: v1
metadata:
name: config-network
namespace: knative-serving
data:
...
...
Configure how HTTP and HTTPS requests are handled in the attribute.
By default, Knative ingress is configured to serve HTTP traffic (
http-protocol: Enabled
). Now that your cluster is configured to use TLS certificates and handle HTTPS traffic, you can specify whether or not any HTTP traffic is allowed.Supported
http-protocol
values:Enabled
: Serve HTTP traffic.Disabled
: Rejects all HTTP traffic.Redirected
: Responds to HTTP request with a302
redirect to ask the clients to use HTTPS.
Example:
apiVersion: v1
kind: ConfigMap
metadata:
name: config-network
namespace: knative-serving
data:
...
auto-tls: Enabled
http-protocol: Redirected
...
Note
When using HTTP-01 challenge,
http-protocol
field has to be set toEnabled
to make sure HTTP-01 challenge requests can be accepted by the cluster.Ensure that the file was updated successfully:
kubectl get configmap config-network -n knative-serving -o yaml
Congratulations! Knative is now configured to obtain and renew TLS certificates. When your TLS certificate is active on your cluster, your Knative services will be able to handle HTTPS traffic.
Verify Auto TLS
Run the following comand to create a Knative Service:
kubectl apply -f https://raw.githubusercontent.com/knative/docs/main/docs/serving/autoscaling/autoscale-go/service.yaml
When the certificate is provisioned (which could take up to several minutes depending on the challenge type), you should see something like:
NAME URL LATESTCREATED LATESTREADY READY REASON
autoscale-go https://autoscale-go.default.{custom-domain} autoscale-go-6jf85 autoscale-go-6jf85 True
Note that the URL will be https in this case.
If you have Auto TLS enabled in your cluster, you can choose to disable Auto TLS for individual services or routes by adding the annotation networking.knative.dev/disable-auto-tls: true
.
Using the previous autoscale-go
example:
Edit the service using
kubectl edit service.serving.knative.dev/autoscale-go -n default
and add the annotation:apiVersion: serving.knative.dev/v1
kind: Service
metadata:
annotations:
...
networking.knative.dev/disable-auto-tls: "true"