Let's Encrypt SSL Certificates for Kubernetes with cert-manager

let's encrypt is a certificate Authority that provides free TLS certificates for websites which you can also take advantage of within your kubernetes cluster in this video we will install search manager in a kubernetes cluster to easily generate and renew certificates for any application running in the cluster in order to obtain a certificate from let's encrypt you will need to install the Acme client which will be responsible for requesting your certificates in kubernetes the client is installed as part of sat manager for the let's encrypt servers to validate that you control the domain name for the certificate they use challenges which your Acme client must solve the first challenge we will use today is the HTTP 01 challenge where let's encrypt will provide the token to your Acme client the Acme client then includes the token together with the thumbprint of your account key in a file which it then presses on your web server the HTTP challenge requires that you have created a DNS error code pointing to the IP address where your web server is reachable in kubernetes this is likely the IP address of your Ingress controller the web server will be a temporary HTTP server pod that is spun up by a search manager service and an Ingress object are also created to enable HTTP access to the HTTP solver pod let's encrypt then tries to retrieve this file several times from different servers if these validation checks get the right responses from your web server the validation is considered successful and the client can go on to issue your certificate a second way in which let's encrypt validate domain ownership is using the dns-01 challenge in this scenario after let's encrypt it gives your admi client a token your client will create a txt record derived from that token a new account key and put that record at Acme challenge dot your domain the Acme client is able to do this by connecting to your DNS provider's API once this new DNS record has successfully propagated through the DNS system let's encrypt will query the DNS system for that record if you it finds a match the client will proceed to issue a certificate of course not all DNS providers are currently supported so you might want to check out the let's encrypt website for a list of supported DNS providers I'll have that information in the readme file Linked In the description below so now that we have a basic overview of how the challenges work let's dive in and get set manager installed on a kubernetes cluster to install search manager run the following command this command will apply the search manager manifest to your kubernetes cluster once we have successfully installed search manager we can now run Cube CTL get pods in the search manager namespace to check that everything installed correctly issuers and cluster issuers are kubernetes resources that represent certificate authorities in the cluster they are able to generate signed certificates by honoring certificate signing requests we create an issuer that issues certificates in only a single namespace and a cluster issuer that issue certificates cluster-wide issuers and crust issuers are capable of working independently and can issue self-signed certificates or can be configured with a trusted root CA certificate or can even register with an upstream certificate Authority like let's encrypt to create an issuer using the HTTP 01 solver run the following command which applies this cluster issue manifest this command creates a cluster issuer named let's encrypt prod it configures the issuer to use the let's encrypt production server specifies an email address for notifications and sets up the http01 server to use nginx Ingress Cube CTL get issuer shows all the cluster issuers set up in the cluster cubectl described cluster issuer shows the status of the cluster issue make sure that the status is ready and that it shows Acme account registered otherwise you might need to double check your configuration for the cluster issuer you might have taken note of the let's encrypt URI I use in this example as the production server both the production and staging servers are red limited to protect from abuse with the staging server having much higher limits so when starting out it is recommended that you start by creating an issuer that uses the staging server just so you can iron out all of the testing issues I have already already run several tests using the staging server and now that I have a working configuration I can confidently use the production issue so now that we have our cluster issue setup we can start issuing certificates for use in our cluster we also need to have a registered domain name for this and as we discussed earlier we need to create a subdomain and point its DNS error code to a server IP address where it will be accessible you can easily do this in the administration panel of your domain registrar I have registered the domain homecube.io with cloudflare and I will demonstrate how you can easily create subdomains and DNS records in the cloudflare panel to use search manager with cloudflare you need to create an error code pointing to the Ingress controller IP address and to do that you can follow these steps go to the cloudflare panel and navigate to DNS and then records and under DNS management click on add a record select a record of type a set the name to a subdomain of your choice set IP address to the Ingress controller IP address click save to create the error code now depending on how your local network is set up you might need to open up Port 80 on your firewall or router and also potentially do put forwarding to your Ingress controller's IP address in order for you to solve the HTTP challenge your Ingress controller must be accessible via the public IP address you configured in the dnsa record if you have set up everything correctly you should be able to now start generating certificates to generate a certificate using search manager run the following command to apply this certificate yaml this command creates a certificate resource named secure home Cube IO in the default namespace it specifies the secret name where the certificate will be stored sets the duration and renewal period defines the subject details create a private key using the RSA algorithm and specifies the DNS name for the certificate the issuerref references the previously created let's encrypt broad cluster issuer the generated certificate for secure.homecube.io will be stored in the specified secret and it will be automatically renewed before expiration based on the renewal period specified after the certificate is issued by sat manager it will be stored in a kubernetes secret you can verify the creation of the secret by running the following commands tubectl get certificate shows the newly created certificate with a ready status set to True Cube CTL get secret lists all the secrets in the default namespace and you should see the newly created secret Cube CTL describe command provides detailed information about the secret including the certificate data and the private key at this point the certificate is successfully created and we can use or press the data stored in the secret to secure applications in the default namespace let's encrypt does not currently support issuing wildcard certificates using the http01 server it can also be possible that we are operating in a network that makes the HTTP server difficult to implement due to some kind of firewall restrictions we can get over these limitations by using the dns-01 solver let's encrypt can connect to the API of a supported DNS provider to automatically issue and renew certificates so let us see how we can upgrade our current configuration to include DNS as a way to validate domain ownership using cloudflare which is a supported DNS provider to authenticate with cloudflare and use the dns-01 solver you need to create an API token in the cloudflare panel go to user profile then API tokens and here under API tokens click create token configure the token with the following settings set the permissions to Zone DNS edit and Zone Zone read and set the Zone resources to include all zones to store the cloudflare API token securely in kubernetes create a secret using the following command replace API token with the actual cloudflare API token value this command creates a secret named cloudflare API token secret with the API token stored securely as the API token key to add a dns-01 challenge solver to the issuer you can modify the existing cluster yaml as follows in this example a dns-01 challenge solver is added to the existing cluster issuer configuration the dns-01 solver uses cloudflare as the DNS provider and the API token secret refers to the secret that contains the cloudflare API token the selector section specifies the DNS names and zones for which the dns-01 challenge solver should be used in this selector configuration certificate requests for the secure.homecube.io subdomain we'll use the HTTP server while all other subdomains ending with homecube.io will use the DNS server to generate a certificate using the updated cluster issuer run the following command this command creates a certificate resource named registry home Cube IO in the Huber namespace the issuerref references the updated let's encrypt prod cluster issuer that now includes the dns-01 solver configuration the generated certificate for registry.homecube.io will be stored in the specified secret and it will be automatically renewed before expiration based on the renewal period specified if you run into any issues while requesting for certificates always refer to Let's encrypts troubleshooting guide which provides some guidance on where issues are likely to occur and how to address them any issues are likely due to a misconfiguration of some kind so you might need to check the status of the Certificate request the order or the challenges for a hint on where the problem could be so we can now use the newly created certificate to secure my hubba registry web portal which as you can see here is using a self-signed certificate and is displaying a warning to use the certificates in an Ingress resource you can create an Ingress yaml file and apply it to the cluster here's an example this yaml file defines an Ingress resource named Harbor Ingress 2 for the hostname registry.homecube.io it redirects HTTP requests to https using SSL redirection and sets the backend Service as Harbor portal listening on put 80. the TLs section specifies the hostname and the secret name where the certificate is stored apply the CML and we should have a new Ingress that will handle the traffic for registry.homecue.io securely using the issued TLS certificate we can refresh our browser page and as you can see the certificate warning has now disappeared you can also click on the padlock icon and navigate to the certificate details for more information about the issued certificates I mentioned earlier that one of the best features of using DNS validation is that it enables us to issue wildcard certificates to secure multiple sub-domains and a single domain with a single certificate creating wildcard certificates Works in pretty much the same way except for the DNS name which would be written as a wild card as shown in this example once created you can use the same certificate to secure multiple subdomains so hopefully at this point you are now able to set up a SAT manager in your cluster and start issuing an automatically renewing certificates for all of your domains don't forget to check out the git project in the description below and leave a like if you enjoyed the video please consider subscribing and I'll see you in the next one

Channel: Engineering with Morris

Views: 9,123

Keywords:

Id: Xv1bdeVnGGY

Length: 13min 7sec (787 seconds)

Published: Fri Jul 07 2023