TLS/X.509 certificates secure all communication between Kubernetes components, using mutual TLS. Mutual TLS offers reliable encrypted and mutually authenticated communications. Both client and server have to identify themselves to the other in a way that can be mutually trusted.
Central to this is the Certificate Authority (CA). It's the entity that everyone else in the cluster trusts, and it has the power to bind client and server identities (eg. usernames or hostnames) to public encryption keys using a digital signature that anyone can verify. When establishing a connection in a Kubernetes cluster, clients and servers alike must offer a TLS certificate that's digitally signed by the a CA server that Kubernetes is configured to trust. They must also prove that they hold the private key associated with that certificate. Only then can a connection be established.
If you plan to run a production Kubernetes cluster, you will be needing several TLS certificates (or dozens, or hundreds) to keep the cluster communicating with itself securely. You'll need to know a few things about Public Key Infrastructure (PKI) and certificate management. So, we've augmented Kubernetes The Hard Way with tutorials for setting up your own internal CA server, issuing certificates for your cluster, and configuring automated renewal.
Why Kubernetes needs certificate automation
Certificates expire and they need to be renewed regularly.
All of the certificates created in Kubernetes The Hard Way expire in one year, and they are created using an offline CA.
So, after a year, your cluster will fall down and all of your certificates will need to be reissued manually.
That's totally fine if you're just using the project to learn Kubernetes, but it's not okay in production.
And if, within that year, someone steals a private key from your cluster, there is no way to for you to revoke the associated certificate. You have to create a new Certificate Authority and, by extension, create and deploy new certificates for everything.
Once you have automation set up for your certificates, you can drop the validity period of your certificates down from a year, to three weeks or even a day. With short-lived certificates, the private key is only valuable for a limited time. If the key is exfiltrated, the damage is limited. The certificate can be revoked by the Certificate Authority, and renewal of the certificate is blocked.
Having an online CA in the mix improves your security posture, and it will keep your cluster running ongoing.
Adding TLS automation to Kubernetes The Hard Way
Hi! I'm Carl from Smallstep Labs, creators of the
step-caopen source, online Certificate Authority. This PR adds support for X.509 certificate automation to Kubernetes The Hard Way.TLS/X.509 certificates secure all communication between Kubernetes components, using mutual TLS. Mutual TLS offers reliable encrypted and mutually authenticated communications. Both client and server have to identify themselves to the other in a way that can be mutually trusted.
Central to this is the Certificate Authority (CA). It's the entity that everyone else in the cluster trusts, and it has the power to bind client and server identities (eg. usernames or hostnames) to public encryption keys using a digital signature that anyone can verify. When establishing a connection in a Kubernetes cluster, clients and servers alike must offer a TLS certificate that's digitally signed by the a CA server that Kubernetes is configured to trust. They must also prove that they hold the private key associated with that certificate. Only then can a connection be established.
If you plan to run a production Kubernetes cluster, you will be needing several TLS certificates (or dozens, or hundreds) to keep the cluster communicating with itself securely. You'll need to know a few things about Public Key Infrastructure (PKI) and certificate management. So, we've augmented Kubernetes The Hard Way with tutorials for setting up your own internal CA server, issuing certificates for your cluster, and configuring automated renewal.
Why Kubernetes needs certificate automation
Certificates expire and they need to be renewed regularly.
All of the certificates created in Kubernetes The Hard Way expire in one year, and they are created using an offline CA. So, after a year, your cluster will fall down and all of your certificates will need to be reissued manually. That's totally fine if you're just using the project to learn Kubernetes, but it's not okay in production.
And if, within that year, someone steals a private key from your cluster, there is no way to for you to revoke the associated certificate. You have to create a new Certificate Authority and, by extension, create and deploy new certificates for everything.
Once you have automation set up for your certificates, you can drop the validity period of your certificates down from a year, to three weeks or even a day. With short-lived certificates, the private key is only valuable for a limited time. If the key is exfiltrated, the damage is limited. The certificate can be revoked by the Certificate Authority, and renewal of the certificate is blocked.
Having an online CA in the mix improves your security posture, and it will keep your cluster running ongoing.
(related blog: Automatic TLS in Kubernetes The Hard Way)