{"id":1375,"date":"2019-02-26T10:55:50","date_gmt":"2019-02-26T10:55:50","guid":{"rendered":"https:\/\/www.appservgrid.com\/paw93\/?p=1375"},"modified":"2019-03-07T20:44:47","modified_gmt":"2019-03-07T20:44:47","slug":"cert-manager-reaches-v0-6-jetstack-blog","status":"publish","type":"post","link":"https:\/\/www.appservgrid.com\/paw93\/index.php\/2019\/02\/26\/cert-manager-reaches-v0-6-jetstack-blog\/","title":{"rendered":"Cert-manager reaches v0.6 \/\/ Jetstack Blog"},"content":{"rendered":"

We\u2019re excited to announce v0.6 of cert-manager<\/a>, the general purpose x509 certificate management tool for Kubernetes. cert-manager provides automated issuance, renewal and management of certificates within your organisation.<\/p>\n

Certificate management in highly dynamic environments is no easy feat, and if approached without careful consideration
\ncould quickly lead to outages and service interuption when certificates begin expiring.
\nBy standardising on a single tool for managing your PKI assets, you can ensure that certificates are being
\nautomatically renewed, and that the appropriate teams are notified if there are any issues or policy violations within
\nyour cluster.<\/p>\n

Over the last year, we\u2019ve seen the project grow rapidly, approaching 3,000 stars on GitHub and with a community of
\nover 100 code contributors, and thousands of people providing support, discussion and insight.<\/p>\n

In this post, we\u2019re going to explore some of the new features of the v0.6 release, as well as discuss our plans for
\nthe project as it works towards a \u201c1.0\u201d release!<\/p>\n

In the past, due to the way that cert-manager was initially designed, we\u2019ve had problems controlling and managing
\ncert-manager\u2019s ACME client usage. This has in some cases lead to excessive use of ACME APIs, which can cause problems
\nfor public ACME providers such as Let\u2019s Encrypt.<\/p>\n

This release significantly refactors how we process and manage ACME certificates, and as a result we\u2019ve seen a net
\nreduction in API usage of up to 100x in some of the worst cases.
\nMaking this change was no small job, and has taken a few months to properly mature into what it is today.<\/p>\n

In order to achieve these improvements, we\u2019ve created \u2018Order\u2019 and \u2018Challenge\u2019 resource types within the Kubernetes API.
\nThis allows us to cache and reason about objects that would usually only exist within the ACME server, using our own
\nAPI. By doing it this way, it also allows more advanced users and integrators to understand and control the ACME Order
\nflow, as we present structured information about the process in the form of our CRDs.<\/p>\n

To summarise, this restructure gives us:<\/p>\n