Free SSL for Kubernetes with Cert-Manager

so how many ssl certificates do you have in your kubernetes cluster and on top of that how many kubernetes clusters do you manage then you probably already know that you have to manually replace all these certificates every time they expire in kubernetes ssl or tla certificates are stored as kubernetes secrets they are generally loaded into namespaces to be consumed by applications or ingress controllers one or two years later they expire and may expire at different intervals causing disruptions if they are missed there are two things that come to mind here number one is human error the more kubernetes clusters and namespaces you own the more secrets you have to manage and maintain there is also room for error when replacing these secrets and you are always bound to miss one or two and have downtime this adds a lot of unnecessary operational overhead number two is security long-lived ssl secrets that don't expire until two years is not great for security and humans interacting with these ssl certificates means that it's leaked from the moment you get them now you can protect these ssl certificates in secrets and kubernetes using rbac but that means cluster admins can still retrieve them if you have a few cluster admins that maintain kubernetes and create these secrets the chances are your certificates are already leaked managing certificates manually as an operational burden that is not worth risking let's encrypt is a certificate authority that allows you to generate free short-lived certificates automatically to get a certificate we run certbot on our web server it asks let's encrypt for a certificate let's encrypt provides a challenge certbot fulfills the challenge let's encrypt provides the certificate this process can be automated with a cron job so the ssl lifecycle becomes self-managed if you're not familiar with let's encrypt check out my let's encrypt introduction video below where i explain the full flow how it works with example source code so how does this work in kubernetes if we have multiple domains and we need multiple ssl secrets in multiple namespaces how do we automate the lifecycle of all these certificates and keep them secure this is where cert manager comes in cert manager lives in your kubernetes cluster you wire it up to a certificate authority like let's encrypt vault and more we simply ask for a certificate using a yaml file in the yaml file we simply say the domain we need a certificate for and the secret where we expect the certificate to be stored in the cert manager will talk to the ca and place the new certificate in the specified kubernetes secret the cert manager will also replace the kubernetes secret with a new one when it's about to expire this means free and automated ssl certificate generation and full certificate lifecycle management so enough with all the theory show me the code [Music] to get started if you take a look at my github repo i have a kubernetes folder and in the kubernetes folder i have a cert manager folder with a readme and in this readme i have all the steps that i'm going to be showing you guys today so be sure to check out the link down below to the source code so you can follow so along get started the first thing we're going to need is a kubernetes cluster so for this i'd like to use a utility called kind which allows me to spin up lightweight kubernetes clusters really fast that i can use for testing so to create a kubernetes cluster we're going to say kind create cluster we're gonna give the cluster a name called cert manager and we're gonna run kubernetes 1.19.1 so i copy this command paste it in the terminal and that will go ahead and create a kubernetes cluster that i can use for testing and then once my cluster is ready i can say cube ct i'll get nodes and we can see we have a one node kubernetes cluster up and running ready to go so if we take a look at the cert manager github repo they have a nice description of what the project is all about we can see we have cert manager over here cert manager looks at a bunch of issuers and we have let's encrypt support cert manager also looks at certificate objects which we can deploy using a yaml file and then it translates the certificate object into a kubernetes secret it also points us to the official documentation which also has a good description of what the project is all about as well as the concepts and in the concepts they talk about the issuer how to wire up let's encrypt to cert manager how to define certificate objects and they talk about certificate requests acme orders and challenges web books ca injectors and the project maturity now we'll take a look at these concepts in a second but if we go back to the github page and we go to the releases section you can then choose the release you want to deploy to your environment and if you scroll down under assets you'll see the cert manager yaml file that defines everything you need to deploy to your kubernetes cluster so you can either download the yaml file directly from here or you can use something like curl and download it so to download cert manager i'm going to change directory to my kubernetes cert manager folder and then i'm going to run curl and i'm going to run call against the releases page url and i'm going to download version 1.0.4 of the cert manager yaml file so i go ahead and run that that'll download the yaml to our machine and then i'm just going to rename the searchmanager.yaml to cert manager 1.0.4.yaml then to deploy cert manager i'm going to create a new name space for it i'm going to say cube ctrl create an insert manager and i'm going to deploy cert manager saying cube ctrl apply validate false minus f and i'm going to pass in the cert manager 1.0.4.0 file that we've just downloaded so if i do that that'll go ahead and create all the custom resource definitions plus the roles and role bindings are back permissions with a service account with our cert manager deployment then to see all the resources that have been deployed i can say cube ctl in the cert manager namespace get all and we can see we have a cert manager pod coming up we have a cert manager ca injector pod as well as a cert manager web hook pod we also have a service to expose the pods we have a deployment and we can see there's no external eyepiece being exposed directly to the public so it's nice and secure within its own namespace and if i do cubectl in the cert manager namespace getpods we can now see we have all three components up and running ready to go so now that we've deployed cert manager we have to go ahead and hook it up with a certificate authority in this demo we'll be using let's encrypt now cert manager will be deploying a bunch of custom resource definitions so new kubernetes objects are introduced in our cluster so to hook up cert manager with let's encrypt we need to deploy an issuer.yaml issuers is a yaml file we'll deploy to define certificate authorities in our case it's let's encrypt then we'll deploy another yaml file which is the actual certificate we need then everything else will happen automatically cert manager will generate a certificate request object then an order object will be generated used for the let's encrypt certificate order a challenge object will be generated used to fulfill the let's encrypt challenge when the challenge is fulfilled by the cert manager the certificate status is automatically completed and a kubernetes secret is created or updated now before we go ahead and use a real ca let's quickly test out whether our cert manager works by creating a self-signed certificate go to test certificate generation i'm just going to create a temporary test namespace i'm going to say cubect i'll create ns and create a namespace called cert manager test then if you take a look at my github repo under kubernetes cert manager i have a self-signed folder with a self-signed issuer.yaml and if we take a look at this this is what an issuer looks like so we say kind as issuer and here we just say that it's a self-signed issuer so to deploy the issuer i say cubect i'll apply minus f in the self-signed folder and i apply the issuer.yaml file this will go ahead and create the issuer for our cert manager to use then i can go ahead and request a certificate by creating a certificate.yaml and in here we can see that kind the certificate we give it the namespace to deploy the certificate to we also specify a dns name for our certificate then we also specify the secret name where to put the actual self-signed certificate so the cert manager will go ahead and request a certificate from the issuer and place the certificate in the secret called self-signed cert-tls and also for a certificate we have to tell it what issuer to use so in this case we say issue a reference and we tell it to use the self-signed issuer that we've just deployed so to create that self-signed server i say cube ct i'll apply minus f in the self-signed folder and i apply the certificate.yaml that'll go ahead and generate a certificate the cert manager will look at that certificate create a certificate request for the issuer and then create the secret for us i can then go ahead and describe that certificate by saying cube ctl describe certificate in the namespace cert manager test and we can see here that we have our self-signed search in the cert manager test namespace kinda certificate and if we scroll down we can see the events and statuses so we can see that issuing certificate as the secret is does not exist it stored a new private key in the temporary secret namespace it created a new certificate request and the issuer has gone ahead and the certificate has been successfully issued to view the certificate i can list the secrets in that namespace and we should see that a self-signed tls has been created as a secret in our cluster ready to be consumed so that is the very basics on how certificate generation works now cert manager has great documentation around the configuration but you can see here that it supports multiple issuer types self signed which is the one i just showed you can use a ca a vault as well as the acme issuer which is let's encrypt now in order for the acme issuer to work your cluster has to have the capability to solve let's encrypt challenges now usually in your kubernetes cluster you have an ingress controller that accepts public traffic now we're going to be using an existing ingress controller to accept incoming web requests for the let's encrypt challenge this will allow us to solve the let's encrypt challenge if you're not familiar with the let's encrypt challenge process check out my video down below on the introduction to let's encrypt where i show the full process and a walkthrough of how to run it all locally so let's go ahead and deploy an ingress controller to our cluster you can also feel free to use your existing ingress controller so to deploy an ingress controller i'm going to create a new namespace called ingress-enginex and in that namespace i'm going to apply the installation yaml file for the ingress controller version 0.414 and i'm gonna take that yaml file and apply it to my kubernetes cluster that'll go ahead and deploy an nginx ingress controller to our kubernetes cluster that we can use to take traffic then to see the ingress controller up and running i can say cube ctl in the ingress nginx namespace i can say get pods and we can see we now have our ingress controller up and running ready to go we can also see if i say cubectl in the ingress nginx namespace getservice i have an ingress controller service type load balancer here that's looking for an external ip if you're running in the cloud you'll get an external ip or a dns name but because i'm running in a kind cluster i won't be getting that so what i'm going to do is i'm going to port forward to port 80 and port 443 so that i can access this ingress controller so to do that i'm going to open up a separate terminal and i'm going to say cubectl in the ingress nginx namespace i'm going to bind to 0.0.0.0 address and i'm going to port forward to the ingress controller on port 80. i'm going to go ahead and run that that'll port forward to my ingress controller and then i'm going to open up another window and i'm going to do exactly the same command but this time for port 443 so i go ahead and run that and now i can open up localhost in the browser and i can hit my ingress controller on port 80. and we can see it's up and running but there's no routes defined so i get a 404 so now that i've deployed an ingress controller to my cluster let's go ahead and get the public ip address of this machine so that we can hook up a dns record to this ip address so to do that i'm just going to say curl ifconfig.co and i'm going to grab the public ip of the server now if you're running in the cloud you probably already have a public ip address on your nginx ingress controller so you can just go ahead and use that so what i'm going to do is i'm going to grab this ip address and i'm going to head over to google domains where i have an existing dns already created and i'm going to go down to custom records and i'm going to add an a record with that ip address that we've gotten from our server once i've updated that i have to wait a while for dns to propagate and once it's propagated i can type the dns in the browser and i can access my nginx ingress controller and we can see that we don't have any ssl certificate so it's coming up with this warning but now our ingress controller is publicly accessible [Music] so now that we have a kubernetes cluster with an ingress controller that can take traffic and we also have cert manager let's go ahead and deploy a let's encrypt issuer to our cluster so similar to our self-signed issuer gamal that we have here we also created a cert issuer nginx ingress yaml which is a cluster issuer for let's encrypt so we say kind as cluster issuer we give it a name and the name is let's encrypt cluster issuer and then we specify spec with the acme settings so we specify the server and this is the production server for let's encrypt we give it an email address we also specify a secret where it can store the issuer key and there are different solvers we can use we can either use a dns solver or an http solver and for this example i'm going to use an http solver and point it to the ingress class which is engine x so to deploy this let's encrypt issuer for our cluster we're gonna say cube ctl apply minus f and we're gonna apply that yaml file so i go ahead and run that and that'll register the let's encrypt issuer on our cert manager i can then check that cert issuer by saying cube ctl describe cluster issuer and i can describe the cluster issuer that we've just deployed and we can see the conditions here the acme account was registered with the acme server and the status is ready so now that everything is ready to go let's go ahead and deploy an example application expose it over our ingress controller and give it a valid ssl certificate so to deploy an example app in my kubernetes folder under deployments folder i have a deployment.yaml with an example application to deploy that example application i simply say cubect i'll apply minus f and i apply the kubernetes deployments folder so i go ahead and run that and that'll go ahead and deploy my example application and create two pods i can say cube ctl get pods and we can see i have two example deployment pods that are coming up now to expose those pods i need to create a service so in the kubernetes services folder i have a service.yaml and this is just creating a basic service for our application so to deploy that service i say cubect i'll apply minus f in the kubernetes services folder that'll go ahead and create our service and if i do cubectl getpods we can see our application is now up and running i can test my application by port forwarding to it so i can say cube ctl port forward to the service and i can port forward to the example service on port 5000 and map that to port 80. and if i run that in the browser we can see we have our hello world application up and running now to expose an application in kubernetes via an ingress we have to deploy an ingress object so in my kubernetes cert manager folder i have an ingress.yaml with a very basic hello world ingress to expose my application to the internet via my ingress controller so i say kind as ingress i give it a name called example app i specified that i wanted tls for this host name that we're going to be using so this is my dns that i'm going to use i also specify a secret name of where the ssl certificate would be located now it's important to know that i currently don't have any ssl certificate located here so we need cert manager to issue that certificate i then also specify a rule saying all traffic from this dns that goes to the root path needs to be mapped to the service that i've just deployed which is the example service on port 80. now if i go ahead and cube ctl apply this yaml file you'll notice that ssl will not be working because there's no secret name called example app tls yet so to get this ssl certificate generated inside of the secret that we've specified here we need to deploy a certificate object for cert manager so in my kubernetes cert manager folder i have a certificate.yaml and if we take a look at that i've described my certificate in here so i just say kinda certificate i give it a name the namespace is default that's where my example app is located i specify the dns which i want the cert to be valid for i then specify the secret name where i want the certificate to be deployed to and then i pass in the issuer reference and here we pass in our cluster issuer that we've deployed earlier and we refer to the let's encrypt cluster issuer that we've deployed earlier so to get the certificate deployed i just say cubect i'll apply minus f and i apply that certificate.yaml file i go ahead and do that that'll deploy the certificate now what will happen is the cert manager will take a look at the certificate issue a certificate request of which an order will be generated the order is the acme certificate order which will also generate a certificate challenge object in kubernetes which will specify the challenge that cert manager has to fulfill once that process is completed we'll be able to see a secret in this namespace now to check the progress i can say cube ctl describe certificate and the name of the certificate that we've just deployed i go ahead and do that and we can see from the event that a certificate has been successfully issued i can then say cubect i'll get secrets and notice that cert manager has gone ahead and created a new secret of type tls to the default namespace and it's called example-app-tls and if i take a look at my ingress.yaml that is the exact same secret name that we're referring to here so now that we have a certificate we can go ahead and deploy our ingress route so i say cube ctl apply minus f in the kubernetes cert manager folder and i apply the ingress.yaml i go ahead and do that and our ingress controller will pick up this rule and will be able to surf traffic publicly so if we go back to the browser and we refresh that domain name we can now see that we have a connection secure we have a valid certificate that's been issued and we can also see we've accessed our hello world service so now we have a let's encrypt browser trusted certificate in a secret in kubernetes cert manager will watch the secret and also update it when it's about to expire so hopefully that gives you a good foundational understanding of cert manager on top of kubernetes and gives you the capability of generating ssl certificates in your kubernetes cluster automatically so let me know down below how do you manage ssl certificates for your kubernetes clusters and if this video helped you remember to like and subscribe and hit the bell and also if you want to support the channel even further be sure to click the join button below and become a member and as always thanks for watching and until next time [Music] peace you

Channel: That DevOps Guy

Views: 16,586

Rating: 4.9821429 out of 5

Keywords: devops, infrastructure, as, code, azure, aks, kubernetes, k8s, cloud, training, course, cloudnative, az, github, development, deployment, containers, docker, messagebroker, messge, broker, aws, amazon, web, services, google, gcp, tls, security, networking, ssl, certs

Id: hoLUigg4V18

Length: 19min 14sec (1154 seconds)

Published: Wed Dec 30 2020

Reddit Comments

[u/Seidoger]

That’s an awful and absurd video tittle.