{"id":441,"date":"2018-10-16T23:41:30","date_gmt":"2018-10-16T23:41:30","guid":{"rendered":"https:\/\/www.appservgrid.com\/paw93\/?p=441"},"modified":"2018-10-17T09:26:38","modified_gmt":"2018-10-17T09:26:38","slug":"automated-certificate-provisioning-in-kubernetes-using-kube-lego-jetstack-blog","status":"publish","type":"post","link":"https:\/\/www.appservgrid.com\/paw93\/index.php\/2018\/10\/16\/automated-certificate-provisioning-in-kubernetes-using-kube-lego-jetstack-blog\/","title":{"rendered":"Automated certificate provisioning in Kubernetes using kube-lego – Jetstack Blog"},"content":{"rendered":"

By Christian Simon<\/a><\/p>\n

In this blog post, we are pleased to introduce Kube-Lego<\/a>, an open source tool for automated Let\u2019s Encrypt TLS-enabled web services running in Kubernetes<\/a>.<\/p>\n

TLS has become increasingly important for production deployment of web services. This has been driven by revelations of surveillance post-Snowden, as well as the fact that Google now favours secure HTTPS sites<\/a> in search result rankings.<\/p>\n

An important step towards increased adoption of TLS has been the availability of
\nLet\u2019s Encrypt<\/a>. It provides an easy, free-of-charge way to obtain certificates. Certificates are limited to a 90-day lifetime and so the free certificate authority (CA) encourages full automation for ease-of-use. At the time of writing, Let\u2019s Encrypt has approaching 3.5 million unexpired certificates<\/a> so adoption has certainly been strong.<\/p>\n

Kube-Lego automates the process in Kubernetes by watching ingress resources and automatically requesting missing or expired TLS certificates from Let\u2019s Encrypt.<\/p>\n

In order to automate the process of verification and certificate issuance for
\nLet\u2019s Encrypt\u2019s CA, the ACME (Automated Certificate Management Environment)
\nprotocol is used. It specifies an API that can be integrated into many products
\nthat require publicly trusted certificates.<\/p>\n

To interact with the CA\u2019s ACME server, clients are required to
\nauthenticate with a private\/public key pair (account). This helps to identify
\nthe user later for actions like extension or revocation of certificates. Let\u2019s
\nEncrypt supports only domain validation and requires you to specify every
\nvalid domain individually, so while a certificate can be valid for multiple
\nhostnames using SAN<\/a>, there is currently no support for wildcard certificates.<\/p>\n

Validation methods<\/h2>\n

Let\u2019s Encrypt allows you to prove the validity of a certificate request
\nwith four methods. They all use a so-called \u2018key auth challenge response\u2019, which
\nis derived from the account\u2019s key pair.<\/p>\n