Shulou(Shulou.com)05/31 Report--

This article mainly introduces how to use cert-manager to issue a free certificate related knowledge, the content is detailed and easy to understand, the operation is simple and fast, has a certain reference value, I believe you will have a harvest after reading this article on how to use cert-manager to issue a free certificate, let's take a look at it.

Overview

With the increasing popularity of HTTPS, more and more websites are upgrading from HTTP to HTTPS. To use HTTPS, you need to apply for a certificate from the authority, which requires a certain cost. If the demand is large, it is also a large expense. Cert-manager is an omnipotent certificate management tool on Kubernetes. If the security level and certificate function are not high, cert-manager can be used to issue free certificates and renew them automatically based on ACME protocol and Let's Encrypt to achieve permanent free use of certificates.

How cert-manager works

After cert-manager is deployed to the Kubernetes cluster, it will watch the CRD resources it supports. We instruct cert-manager to issue certificates for us and renew automatically by creating CRD resources:

Explain several key resources:

Issuer/ClusterIssuer: used to instruct cert-manager to issue certificates. This article focuses on the ACME method of issuing free certificates. The only difference between ClusterIssuer and Issuer is that Issuer can only be used to issue certificates under its own namespace, while ClusterIssuer can issue certificates under any namespace.

Certificate: the certificate used to tell cert-manager what domain name we want and some configuration needed to issue the certificate, including a reference to Issuer/ClusterIssuer.

Principle of issuing free certificate

Let's Encrypt uses the ACME protocol to verify whether the domain name really belongs to you. After the verification is successful, you can automatically issue a free certificate. The certificate is valid for only 90 days. Before it expires, you need to verify it again to renew it. Fortunately, cert-manager can renew it automatically, so you can use a permanent free certificate. How to verify whether this domain name belongs to you? The two mainstream verification methods are HTTP-01 and DNS-01. For more information on the verification principle, please refer to the operation mode of Let's Encrypt, which is briefly described below.

HTTP-01 check principle

The verification principle of HTTP-01 is to add a temporary location to the HTTP service that your domain name points to. Let's Encrypt will send a http request to the http:///.well-known/acme-challenge/ domain name that is verified. TOKEN is the file placed by the client of ACME protocol, where the ACME client is cert-manager. It adds this temporary verification path and points to the service that provides TOKEN by modifying or creating Ingress rules. Let's Encrypt will compare whether the TOKEN meets expectations, and a certificate will be issued after the verification is successful. This method applies only to issuing certificates to services that expose traffic using Ingress, and does not support pan-domain name certificates.

DNS-01 check principle

The principle of DNS-01 verification is to use the API Key of the DNS provider to get your DNS control. After Let's Encrypt provides the token to the ACME client, the ACME client (cert-manager) will create a TXT record derived from the token and your account key and place the record in _ acme-challenge. Let's Encrypt will then query the DNS system for the record, and if a match is found, a certificate can be issued. This method does not require your service to use Ingress and supports pan-domain name certificates.

Comparison of calibration methods

The advantage of HTTP-01 verification method is that the configuration is simple and universal, and no matter which DNS provider you use, you can use the same configuration method; the disadvantage is that you need to rely on Ingress, which is not applicable if your service does not expose traffic with Ingress, and does not support pan-domain name certificates.

The advantage of DNS-01 verification method is that it has no disadvantages of HTTP-01 verification method, does not rely on Ingress, and supports pan-domain names. The disadvantage is that different DNS providers have different configurations, and there are many DNS providers, so it is impossible for cert-manager 's Issuer to support each of them. However, some services that implement cert-manager can be deployed to extend Issuer support, such as DNSPod and Ali DNS. For more information on Webhook list, please see https://cert-manager.io/docs/configuration/acme/dns01/#webhook.

Which way do you choose? If conditions permit, it is recommended to use DNS-01 as far as possible, with fewer restrictions and more complete functions.

Steps to install cert-manager

Usually use yaml to install cert-manager to the cluster with one click, refer to the official website document Installing with regular manifests.

The image officially used by cert-manager is in quay.io, and it may be slow to pull it domestically, or you can install it with one click using the following command (use the image synchronized to the domestic CCR):

Kubectl apply-- validate=false-f https://raw.githubusercontent.com/TencentCloudContainerTeam/manifest/master/cert-manager/cert-manager.yaml

! The above command installation method requires that the cluster version is not less than 1.16.

Configure DNS

Log in to the backend of your DNS provider, configure the DNS A record of the domain name, and point to the IP address exposed by the backend service for which you need a certificate. Take cloudflare as an example:

Certificate issued by HTTP-01 verification

If you use the HTTP-01 verification method, you need to use Ingress to cooperate with the verification. Cert-manager automatically modifies Ingress rules or automatically adds Ingress to achieve the temporary HTTP path required for external exposure verification. This is configuring http01 verification for Issuer and specifying the difference between name or class of Ingress (see the example below).

The Ingress that comes with TKE is that each Ingress resource corresponds to a CLB. If you use the Ingress exposure service that comes with TKE and use HTTP-01 verification, you can only use the method of automatically modifying Ingress and not automatically adding Ingress, because the newly added Ingress will automatically create other CLB, and the external IP address is not the same as the Ingress of our backend service. During the Let's Encrypt verification, the temporary path required for the verification cannot be found from the Ingress we serve, resulting in the verification failure and the certificate cannot be issued. If you use a self-built Ingress, such as deploying Nginx Ingress on TKE, the Ingress of the same Ingress class shares the same CLB, so you can use the method of automatically adding Ingress.

Here are some examples.

If your service uses the Ingress exposure service that comes with TKE, it is not suitable to use cert-manager to sign and manage free certificates, because certificates are uploaded to certificate management to reference, not managed in K8S.

Suppose you deploy Nginx Ingress on TKE, and the Ingress of the backend service is prod/web, create an Issuer example:

ApiVersion: cert-manager.io/v1kind: Issuermetadata: name: letsencrypt-http01 namespace: prodspec: acme: server: https://acme-v02.api.letsencrypt.org/directory privateKeySecretRef: name: letsencrypt-http01-account-key solvers:-http01: ingress: name: web # specifies the Ingress name that is automatically modified

Using the above Issuer to issue the certificate, cert-manager automatically modifies the Ingress resource prod/web to expose the temporary path required for verification. This is the way to automatically modify Ingress. You can use the method of automatically adding Ingress. Example:

ApiVersion: cert-manager.io/v1kind: Issuermetadata: name: letsencrypt-http01 namespace: prodspec: acme: server: https://acme-v02.api.letsencrypt.org/directory privateKeySecretRef: name: letsencrypt-http01-account-key solvers:-http01: ingress: class: nginx # specifies the ingress class of the automatically created Ingress

Using the Issuer above to issue the certificate, cert-manager automatically creates an Ingress resource to expose the temporary path required for verification.

With Issuer, you can create a Certificate and refer to Issuer for signing. For example:

ApiVersion: cert-manager.io/v1kind: Certificatemetadata: name: test-mydomain-com namespace: prodspec: dnsNames:-test.mydomain.com # the domain name to be issued issuerRef: kind: Issuer name: letsencrypt-http01 # refers to Issuer, indicating that secretName: test-mydomain-com-tls # will be verified by http01. The certificate finally issued will be saved in this Secret. The certificate will be issued by DNS-01 verification.

If you use DNS-01 verification, you need to see which DNS provider you use. Cert-manager has built-in support from some DNS providers. For a detailed list and usage, please refer to Supported DNS01 providers, but it is impossible for cert-manager to support all DNS providers. What if you don't have the DNS provider you use? There are two options:

Scheme 1: set up Custom Nameserver. Set custom nameserver in your DNS provider backend to point to nameserver addresses such as cloudflare that can manage the domain names of other DNS providers. You can log in to cloudflare backend to check the specific address:

The following is an example of namecheap setting up custom nameserver:

When you finally configure Issuer to specify DNS-01 authentication, you can add some information about cloudflare (see the example below).

Plan 2: use Webhook. Using cert-manager 's Webhook to extend the DNS providers supported by cert-manager 's DNS-01 verification, there are many third-party implementations, including DNSPod and Ali DNS, which are commonly used in China. For more information, please see Webhook.

Take cloudflare as an example to issue a certificate:

Log in to cloudflare and click My Profile > API Tokens > Create Token to create the Token:

Copy the Token and keep it safe:

Save Token to Secret:

ApiVersion: v1kind: Secretmetadata: name: cloudflare-api-token-secret namespace: cert-managertype: OpaquestringData: api-token: # paste Token here without base64 encryption.

! If you want to create a ClusterIssuer,Secret, you need to create it in the same namespace as cert-manager, and if it is Issuer, create it in the same namespace as Issuer.

Create a ClusterIssuer:

ApiVersion: cert-manager.io/v1kind: ClusterIssuermetadata: name: letsencrypt-dns01spec: acme: privateKeySecretRef: name: letsencrypt-dns01 server: https://acme-v02.api.letsencrypt.org/directory solvers:-dns01: cloudflare: email: my-cloudflare-acc@example.com # replace your cloudflare email account. API Token authentication is not required. API Keys authentication is required: apiTokenSecretRef: key: api-token name: cloudflare-api-token-secret # reference the Secret that holds the cloudflare authentication information

Create a Certificate:

ApiVersion: cert-manager.io/v1kind: Certificatemetadata: name: test-mydomain-com namespace: defaultspec: dnsNames:-test.mydomain.com # the domain name issuerRef: kind: ClusterIssuer name: letsencrypt-dns01 # refers to ClusterIssuer, indicating that secretName: test-mydomain-com-tls # will be verified by dns01. The final certificate will be saved in this Secret.

Obtain and use certificates

After the Certificate is created, wait a little while, we can kubectl to see if it has been successfully issued:

$kubectl get certificate-n prodNAME READY SECRET AGEtest-mydomain-com True test-mydomain-com-tls 1m

If READY is False, you can check event through describe to troubleshoot the cause of the failure:

$kubectl describe certificate test-mydomain-com-n prod

If the True is issued successfully, the certificate is stored in the Secret we specified (the above example is default/test-mydomain-com-tls), which can be viewed through kubectl:

$kubectl get secret test-mydomain-com-tls-n default...data: tls.crt: tls.key:

Where tls.crt is the certificate and tls.key is the key.

You can mount them to applications where you need certificates, or use self-built Ingress. You can reference secret directly in Ingress, for example:

ApiVersion: networking.k8s.io/v1beta1kind: Ingressmetadata: name: test-ingress annotations: kubernetes.io/Ingress.class: nginxspec: rules:-host: test.mydomain.com http: paths:-path: / web backend: serviceName: web servicePort: 80 tls: hosts:-test.mydomain.com secretName: test-mydomain-com-tls on "how to use cert-manager to issue a free certificate" This is the end of the article on the Book. Thank you for reading! I believe you all have a certain understanding of "how to use cert-manager to issue free certificates". If you want to learn more, you are welcome to follow the industry information channel.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.