Shulou(Shulou.com)06/01 Report--

This article mainly introduces how to use K3s to easily manage SSL certificates, has a certain reference value, interested friends can refer to, I hope you can learn a lot after reading this article, the following let the editor with you to understand.

Prepare for

To continue reading this article, you will need the K3s raspberry pie cluster we built in the previous article. In addition, you need to have a public static IP address and a domain name for which you can create DNS records. If you have a dynamic DNS provider that provides domain names for you, it may also work. However, in this article, we use static IP and CloudFlare to manually create the A record for DNS.

When we create configuration files in this article, if you don't want to type them, you can download them here.

Why do we use cert-manager?

Traefik (pre-bundled in K3s) actually has built-in Let's Encrypt support, so you might wonder why we install third-party packages to do the same thing. At the time of this writing, Let's Encrypt in Traefik supports the retrieval of certificates and storing them in files. Cert-manager retrieves the certificate and stores it in Kubernetes's Confidential Information secret. In my opinion, "confidential information" can be simply referenced by name, so it is easier to use. This is the main reason why we use cert-manager in this article.

Install cert-manager

Usually, we just follow cert-manager 's documentation to install on Kubernetes. However, because we are using the ARM architecture, we need to make some changes so that we can do this.

The first step is to create the cert-manager namespace. Namespaces help exclude cert-manager 's Pod from our default namespace, so when we use our own Pod to perform operations such as kubectl get pods, we don't have to see them. Creating a namespace is simple:

Kubectl create namespace cert-manager

The installation instructions will allow you to download cert-manager 's YAML configuration file and apply it all to your cluster in one step. We need to break it down into two steps to modify the file for ARM-based raspberry pie. We will download the file and convert it step by step:

Curl-sL\ https://github.com/jetstack/cert-manager/releases/download/v0.11.0/cert-manager.yaml |\ sed-r's / (image:.*): (v.*) $/\ 1-arm:\ 2According g'> cert-manager-arm.yaml

This downloads the configuration file and updates all included docker images to the ARM version. Let's check what it does:

$grep image: cert-manager-arm.yaml image: "quay.io/jetstack/cert-manager-cainjector-arm:v0.11.0" image: "quay.io/jetstack/cert-manager-controller-arm:v0.11.0" image: "quay.io/jetstack/cert-manager-webhook-arm:v0.11.0"

As we can see, the three mirrors now add-arm to the image name. Now that we have the correct file, we just need to apply it to the cluster:

Kubectl apply-f cert-manager-arm.yaml

This will install all of cert-manager. We can use kubectl-- namespace cert-manager get pods to check when the installation is complete until all Pod is in the Running state.

This completes the installation of cert-manager!

Overview of Let's Encrypt

The advantage of Let's Encrypt is that it provides us with publicly verified TLS certificates for free! This means that we can have a fully effective TLS encrypted website that anyone can visit, these family or hobby activities do not make money, and there is no need to buy TLS certificates out of our own pocket! And, when using Let's Encrypt's certificate through cert-manager, the whole process of obtaining the certificate is automated and the renewal of the certificate is automatic!

But how does it work? The following is a simplified description of the process. We (or on behalf of our cert-manager) send a certificate request to Let's Encrypt for the domain name we own. Let's Encrypt verifies that we own the domain by using the ACME DNS or HTTP authentication mechanism. If the verification is successful, Let's Encrypt will provide us with certificates that will be installed by cert-manager on our website (or other TLS encrypted endpoints). These certificates can be used for 90 days before this process needs to be repeated. However, cert-manager will automatically update the certificate for us.

In this article, we will use the HTTP validation method because it is easier to set up and works in most cases. The following is the basic process that happens behind the scenes. Cert-manager issues a certificate request to Let's Encrypt. In response, Let's Encrypt issues the ownership verification challenge challenges. This challenge places a HTTP resource on a specific URL under the domain name requesting the certificate. In theory, if we can put the resource on the URL and make it available to Let's Encrypt remotely, then we must actually be the owner of the domain. Otherwise, either we can't put the resource in the right place, or we can't manipulate the DNS so that Let's Encrypt can access it. In this case, cert-manager puts the resources in the right place and automatically creates a temporary Ingress record to route traffic to the correct location. If Let's Encrypt can read the resource required by the challenge and is correct, it will send the certificate back to cert-manager. Cert-manager stores certificates as "confidential information", and then our website (or any other website) will use these certificates to protect our traffic through TLS.

Set up the network for the challenge

I assume that you want to set up on your home network and have a router / access point that somehow connects to the wider Internet. If this is not the case, the following procedure may not be required.

In order for the challenge process to work properly, we need a domain name that we want to apply for a certificate to route to the K3s cluster on port 80. To do this, we need to tell the world's DNS system where it is. Therefore, we need to map the domain name to our public IP address. If you don't know what your public IP address is, you can visit places like WhatsMyIP and it will tell you. Next, we need to enter the A record of DNS, which maps our domain name to our public IP address. For this feature to work reliably, you need a static public IP address, or you can use a dynamic DNS provider. Some dynamic DNS providers will give you a domain name, and you can use it according to the following instructions. I haven't tried it, so I can't say for sure that it applies to all providers.

For this article, we assume that we have a static public IP and use CloudFlare to set the A record of the DNS. You can use your own DNS server if you prefer. The important thing is that you can set the A record.

In the rest of this article, I'll use k3s.carpie.net as the sample domain name, because this is the domain I own. You will obviously replace it with any domain name you own.

For example, suppose our public IP address is 198.51.100.42. We go to the DNS record section of our DNS provider and add a record of type A named k3s.carpie.net (CloudFlare already assumes part of the domain, so we just need to enter k3s), and then enter 198.51.100.42 as the IPv4 address.

Note that sometimes DNS updates take a while to propagate. It may take you several hours to resolve the name. The name must be resolvable before continuing. Otherwise, all our certificate requests will fail.

We can use the dig command to check whether the name is resolved:

$dig + short k3s.carpie.net198.51.100.42

Continue to run the above command until you can return IP. A little note about CloudFlare: ClouldFlare provides a service that hides your actual IP through proxy traffic. In this case, we are getting back CloudFlare's IP, not our IP. But for our purposes, this should work properly.

The final step in network configuration is to configure the router to route incoming traffic on ports 80 and 443 to our K3s cluster. Sadly, the router configuration pages vary so much that I can't tell you exactly what you look like. Most of the time, the administrative page we need is under "port forwarding" or something like that. I've even seen it listed under "games" (obviously the games that port forwarding is mainly used for)! Let's see how my router is configured.

If your environment is the same as mine, go to 192.168.0.1 and log in to the router management application. For this router, it is located at "NAT/QoS"-> "Port forwarding". Here, we set the port 80/TCP protocol to forward to port 80 of 192.168.0.50 (the IP of the primary node kmaster). We also set port 443 to map to kmaster. Technically, this is not necessary for a challenge, but at the end of this article, we will deploy a TLS-enabled Web site and need to map 443 for access. Therefore, it is convenient to map now. We save and apply the changes, and everything should go well!

Configure cert-manager to use Let's Encrypt (staging environment)

Now we need to configure cert-manager to issue certificates through Let's Encrypt. Let's Encrypt provides us with a temporary storage (for example, for testing) environment to review our configuration. This makes it more tolerant of errors and requests. If we do something wrong with the production environment, we will soon find ourselves temporarily banned! Therefore, we will test the request manually using a staging environment.

Create a file letsencrypt-issuer-staging.yaml with the following contents:

ApiVersion: cert-manager.io/v1alpha2kind: ClusterIssuermetadata: name: letsencrypt-stagingspec: acme: # The ACME server URL server: https://acme-staging-v02.api.letsencrypt.org/directory # Email address used for ACME registration email: @ example.com # Name of a secret used to store the ACME account private key privateKeySecretRef: name: letsencrypt-staging # Enable the HTTP-01 challenge provider solvers:-http01: ingress: class: traefik

Please be sure to update your email address to your address. If something goes wrong or we break something, this is how Let's Encrypt contacts us!

Now, let's create the publisher issuer using the following methods:

Kubectl apply-f letsencrypt-issuer-staging.yaml

We can check whether the publisher has successfully created it using the following methods:

Kubectl get clusterissuers

Clusterissuers is a new Kubernetes resource type created by cert-manager.

Now let's manually request a test certificate. For our site, we don't need to do this; we're just testing the process to make sure our configuration is correct.

Create a certificate request file le-test-certificate.yaml that contains the following:

ApiVersion: cert-manager.io/v1alpha2kind: Certificatemetadata: name: k3s-carpie-net namespace: defaultspec: secretName: k3s-carpie-net-tls issuerRef: name: letsencrypt-staging kind: ClusterIssuer commonName: k3s.carpie.net dnsNames:-k3s.carpie.net

This record simply means that we want to use a ClusterIssuer named letsencrypt-staging (which we created in the previous step) to request a certificate for the domain k3s.carpie.net and store the certificate in a file named k3s-carpie-net-tls in Kubernetes's secret information.

Apply it as usual:

Kubectl apply-f le-test-certificate.yaml

We can view the status in the following ways:

Kubectl get certificates

If we see something like the following:

NAME READY SECRET AGEk3s-carpie-net True k3s-carpie-net-tls 30s

We are on the road of happiness! The key here is that READY should be True.

Resolve the issue of certificates

Above is the road to happiness. If READY is False, we can wait for it and then take some time to check the status again. If it is always False, then we have problems that need to be solved. At this point, we can traverse the Kubernetes resource chain until we find a status message that tells us the problem.

Suppose we executed the above request and READY is False. We can start troubleshooting in the following ways:

Kubectl describe certificates k3s-carpie-net

This will return a lot of information. Typically, useful content is located in the Events: section, which is usually at the bottom. Suppose the last event is Created new CertificateRequest resource "k3s-carpie-net-1256631848. Then let's describe the request by describe:

Kubectl describe certificaterequest k3s-carpie-net-1256631848

Now, for example, the last event is Waiting on certificate issuance from order default/k3s-carpie-net-1256631848-2342473830.

Then, we can describe the order:

Kubectl describe orders default/k3s-carpie-net-1256631848-2342473830

Suppose you have an event, which is Created Challenge resource "k3s-carpie-net-1256631848-2342473830-1892150396" for domain "k3s.carpie.net". Let's describe the question:

Kubectl describe challenges k3s-carpie-net-1256631848-2342473830-1892150396

The last event returned from here is Presented challenge using http-01 challenge mechanism. It looks fine, so let's browse through the output of the description and see a message Waiting for http-01 challenge propagation: failed to perform self check GET request. No such host . finally! We found a problem! In this case, no such host means that the DNS lookup failed, so we need to go back and manually check our DNS settings, correctly parse the domain's DNS, and make any changes we need.

Clean up our test certificates

What we actually want to use is the real certificate of the domain name, so let's continue to clean up the certificate and the confidential information we just created:

Kubectl delete certificates k3s-carpie-netkubectl delete secrets k3s-carpie-net-tls configures cert-manager to use Let's Encrypt (production environment)

Now that we have the test certificate, it's time to move to the production environment. Just as we configured cert-manager in the Let's Encrypt staging environment, we now need to do the same for the production environment. Create a file called letsencrypt-issuer-production.yaml (you can copy and modify the file for the staging environment if necessary) with the following contents:

ApiVersion: cert-manager.io/v1alpha2kind: ClusterIssuermetadata:name: letsencrypt-prodspec:acme: # The ACME server URL server: https://acme-v02.api.letsencrypt.org/directory # Email address used for ACME registration email: @ example.com # Name of a secret used to store the ACME account private key privateKeySecretRef: name: letsencrypt-prod # Enable the HTTP-01 challenge provider solvers:-http01: ingress: class: traefik

If you are replicating from a staging environment, the only change is server: URL. Please also don't forget to modify your email! )

Apply it:

Kubectl apply-f letsencrypt-issuer-production.yaml apply for the certificate of our website

It is important to note that all the steps we have completed so far need to be done only once! For any other applications in the future, we can start with this description!

Let's deploy the same site that we deployed in the previous article. (if it is still available, you can modify the YAML file. If not, you may need to recreate and redeploy it.

We just need to change the Ingress part of the mysite.yaml to:

-apiVersion: networking.k8s.io/v1beta1kind: Ingressmetadata: name: mysite-nginx-ingress annotations: kubernetes.io/ingress.class: "traefik" cert-manager.io/cluster-issuer: letsencrypt-prodspec: rules:-host: k3s.carpie.net http: paths:-path: / backend: serviceName: mysite-nginx-service servicePort: 80 tls:-hosts:-k3s.carpie.net secretName: k3s-carpie-net-tls

Notice that only the Ingress portion of mysite.yaml is shown above. The change is to add the annotation cert-manager.io/cluster-issuer: letsencrypt-prod. This tells traefik which publisher to use when creating the certificate. The only other addition is the tls: block. This tells traefik that we want to have TLS functionality on the host k3s.carpie.net, and that we want the TLS certificate file to be stored in the confidential information k3s-carpie-net-tls.

Remember, we didn't create these certificates! Well, we created test certificates with similar names, but we deleted them. Traefik will read these configurations and continue to look for confidential information. When it cannot be found, it will see a comment saying that we want to use the letsencrypt-prod publisher to get it. Therefore, it will make a request and install the certificate into the confidential information for us!

Thank you for reading this article carefully. I hope the article "how to easily manage SSL certificates with K3s" shared by the editor will be helpful to everyone. At the same time, I also hope you can support us and pay attention to the industry information channel. More related knowledge is waiting for you to learn!

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.