Enabling Automatic TLS Certificate Provisioning for Cloud Native Runtimes

You can configure Cloud Native Runtimes to automatically obtain and renew TLS certificates for your workloads. Automatic TLS certificate provisioning allows you to secure your clusters and domains without manually generating or renewing certificates. Automatic TLS certificate provisioning reduces the manual certificate workload for admins and developers.

Cloud Native Runtimes supports both HTTP01 and DNS01 cert-manager challenge types. For more information about cert-manager challenge types, see ACME in the cert-manager documentation.

VMware recommends using Let’s Encrypt as your certificate authority. However, you can integrate Cloud Native Runtimes with any ACME compatible certificate authority.

Prerequisites

You can enable HTTPS with Automatic TLS certificate provisioning for Cloud Native Runtimes.

You need the following prerequisites to use secure HTTPS connections with automatic TLS certificate provisioning:

A cluster configured to use a custom domain. See Setting Up a Custom Domain in the Knative documentation.
A DNS provider configured with your domain name.
cert-manager version 1.0.0 or later. See Installing cert-manager for TLS certificates in the Knative documentation.
HTTP01 challenges: An internet-reachable cluster.
DNS01 challenges: API access to set DNS records.

Enable Auto TLS Using an HTTP01 Challenge

You can use the HTTP01 challenge type to validate a domain with Cloud Native Runtimes. The HTTP01 challenge requires that your load balancer be reachable from the internet via HTTP.

Note: With the HTTP01 challenge type, you provision a certificate for each service.

To enable automatic TLS certificate provisioning using a HTTP01 challenge, do the following:

Create a cert-manager Issuer or ClusterIssuer for the HTTP01 challenge. See Issuer in the cert-manager documentation. The following example creates a ClusterIssuer using the Let’s Encrypt Certificate Authority. See Let’s Encrypt. To use a ClusterIssuer for the HTTP01 challenge, run:

kubectl apply -f - <<EOF
apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
  name: letsencrypt-http01-issuer
spec:
  acme:
    privateKeySecretRef:
      name: letsencrypt
    server: https://acme-v02.api.letsencrypt.org/directory
    solvers:
    - http01:
        ingress:
          class: contour
EOF

To validate that your ClusterIssuer was created successfully, run:

kubectl get clusterissuer letsencrypt-http01-issuer --output yaml

Edit your config-certmanager ConfigMap in the knative-serving namespace to reference the ClusterIssuer you created. Run:
```
kubectl edit configmap config-certmanager --namespace knative-serving
```
To define which ClusterIssuer will be used by Knative to issue certificates, add the following issuerRef block under the data section of the config-certmanager ConfigMap:
```
...
data:
...
 issuerRef: |
   kind: ClusterIssuer
   name: letsencrypt-http01-issuer
```

To validate that your ConfigMap was updated successfully, run:

kubectl get configmap config-certmanager --namespace knative-serving --output jsonpath="{.data.issuerRef}"

Edit the config-network ConfigMap in the knative-serving namespace to enable automatic TLS certificate provisioning and specify how HTTP requests are handled. Run:
```
kubectl edit configmap config-network --namespace knative-serving
```
Note: For HTTP01 challenges, the httpProtocol field must be set to Enabled for the cluster to accept HTTP01 challenge requests.
```
apiVersion: v1
kind: ConfigMap
metadata:
 name: config-network
 namespace: knative-serving
data:
 ...
 autoTLS: Enabled
 ...
 httpProtocol: Enabled
 ...
```

To validate that your ConfigMap was updated successfully, run:

kubectl get configmap config-network --namespace knative-serving --output jsonpath="{.data.autoTLS}"
kubectl get configmap config-network --namespace knative-serving --output jsonpath="{.data.httpProtocol}"

Verify that your automatic TLS certificate instance is configured correctly by deploying a sample app. See Verify Auto TLS in the Knative documentation.

Enable Auto TLS Using a DNS01 Challenge

The DNS01 challenge validates that you control your domain’s DNS by accessing and updating your domain’s TXT record. You need to provide a cert-manager with your DNS API credentials. For a list of DNS01 providers supported for the ACME Issuer, see the cert-manager documentation.

Note: You can provision certificates per service only.

To enable automatic TLS certificate provisioning using a DNS01 challenge, do the following:

Set up credentials for cert-manager to access your DNS records. For information about setting up credentials for your ACME Issuer supported DNS provider, see Supported DNS01 providers in the cert-manager documentation. In the next step, you create an Issuer on cert-manager with the configuration you set up.

Create a cert-manager Issuer or ClusterIssuer for DNS01 challenge on the cert-manager Issuer you set up in the previous step. The following example uses Let’s Encrypt and Google Cloud DNS. For information about other DNS providers supported by cert-manager, see the cert-manager documentation. The Issuer assumes that your Kubernetes secret holds credentials for the service account created. Run the following command to apply the ClusterIssuer:

kubectl apply --filename - <<EOF
apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
  name: letsencrypt-dns-issuer
spec:
  acme:
    server: https://acme-v02.api.letsencrypt.org/directory
    # This will register an issuer with LetsEncrypt.
    email: MY-EMAIL 
    privateKeySecretRef:
      # Set privateKeySecretRef to any unused secret name.
      name: letsencrypt-dns-issuer
    solvers:
    - dns01:
        cloudDNS:
          project: $PROJECT_ID
          # Set this to the secret that we publish our service account key
          # in the previous step.
          serviceAccountSecretRef:
            name: cloud-dns-key
            key: key.json
EOF

Where MY-EMAIL is your email address.

To verify that your ClusterIssuer is created successfully, run:

kubectl get clusterissuer letsencrypt-dns-issuer --output yaml

Edit your config-certmanager ConfigMap in the knative-serving namespace to reference the ClusterIssuer created in the previous step. Run:
```
kubectl edit configmap config-certmanager --namespace knative-serving
```
Add an issuerRef block under the data section of your ConfigMap. This defines the ClusterIssuer Knative uses to issue certificates. Run:
```
...
data:
...
 issuerRef: |
   kind: ClusterIssuer
   name: letsencrypt-dns-issuer
```

To validate that your file was updated successfully, run:

kubectl get configmap config-certmanager --namespace knative-serving --output jsonpath="{.data.issuerRef}"

To enable automatic TLS certificate provisioning and specify how HTTP requests are handled, edit your config-network ConfigMap in the knative-serving namespace:
```
kubectl edit configmap config-network --namespace knative-serving
```
Note: When using the DNS01 challenge type, the httpProtocol field must be set to Enabled.
```
apiVersion: v1
kind: ConfigMap
metadata:
 name: config-network
 namespace: knative-serving
data:
 ...
 autoTLS: Enabled
 ...
 httpProtocol: Enabled
 ...
```

Validate that your file was updated successfully. Run:

kubectl get configmap config-network --namespace knative-serving --output jsonpath="{.data.autoTLS}"
kubectl get configmap config-network --namespace knative-serving --output jsonpath="{.data.httpProtocol}"

Verify that your automatic TLS certificate instance is functioning correctly by deploying a sample app. See Verify Auto TLS in the Knative documentation.