2\/May 2018<\/p>\n
By James Munnelly<\/a><\/p>\n Those of you who closely follow Jetstack\u2019s open source projects<\/a> may have already noticed that our Cert-manager is a general purpose x509 certificate management tool for Kubernetes. kube-lego<\/a>, our original<\/a> Let\u2019s Encrypt<\/a> certificate provisioning By building cert-manager around Kubernetes CustomResourceDefinitions<\/a>, we have been able to This post is a high-level overview of how cert-manager works, and will highlight In the real world of x509 certificates, CAs (Certificate Authorities) are a point of trust, responsible Let\u2019s Encrypt introduced the ACME protocol, however, not all CAs support this protocol.<\/p>\n In order to support many different types of certificate authority, we have introduced the concept of A cert-manager \u2018Issuer\u2019 resource represents an entity that is able to sign x509 Certificate Today, we support ACME, CA (i.e. a simple signing keypair stored in a Secret resource) and as of Here\u2019s an example of an issuer resource:<\/p>\n apiVersion: certmanager.k8s.io\/v1alpha1 In order to request certificates from these Issuers, we also introduce Certificate resources. Here\u2019s an example of a certificate resource, using the issuer shown previously:<\/p>\n apiVersion: certmanager.k8s.io\/v1alpha1 More info on Issuers and Certificates can be found in our documentation<\/a>.<\/p>\n Over the last few weeks, we have been trialling an alpha release candidate of v0.3, This release is packed with new features and bug fixes alike, and this section describes Let\u2019s Encrypt recently announced v2 of the ACME protocol, which amongst other improvements, In order to allow cert-manager users to request and consume wildcard certificates, we have This allows users to request wildcard certificates just like any other – including full support This is a great example of how we can add new and more complex features to cert-manager, whilst If you\u2019d like to get started and give this a try, check out the latest v0.3 alpha release After a lot of hard work, initial support for Hashicorp Vault<\/a> has been merged into cert-manager!<\/p>\n This is another long requested feature, and a large addition to our set of supported Issuer types.<\/p>\n A special thanks to @vdesjardins<\/a>, who single handedly and unprompted undertook this work, driving This allows end users to create a \u2018Vault\u2019 Issuer, which is paired with a single Vault PKI backend role.<\/p>\n Initially we support both token authentication and Vault\u2019s \u2018AppRole\u2019 authentication mechanism The addition of the Vault Issuer bolsters our position as a general purpose certificate Read more about creating and using the Vault Issuer<\/a> at the docs.<\/p>\n Within any project, documentation is tough. It needs to provide a clear onboarding experience We\u2019ve had some brilliant community contributions with user guides and tutorials explaining how Up until now, we have used markdown stored in GitHub to host our documentation. You can check out the new docs on readthedocs<\/a> – take note Each page in the docs also has an \u201cEdit in GitHub\u201d link on the top right, so if you spot a mistake Cert-manager is still young, with much planned in the future! Here are a couple of highlights Right now, any user that is able to create a Certificate resource can request certificates We intend to provide mechanisms for administrators to define \u2018policies\u2019 for who can obtain By defining this policy within Kubernetes itself, we benefit from a common level of policy Kubernetes has recently added support for ValidatingAdmissionWebhooks (as well as their \u2018Mutating\u2019 counterparts).<\/p>\n These can be used to provide resource validation (e.g. ensuring that all fields are set to One common problem when configuring these webhooks, is that they require x509 Certificates in order In future releases of cert-manager, we will introduce our own<\/em> Validating webhook in Along with this, we will be creating tutorials that explain our \u2018recommended deployment practice\u2019 Some enterprise users of cert-manager have their own CA process, which is novel and bespoke It is not always feasible to switch a whole organisation over to a new protocol in a short period, In order to ease the transition period for these companies, we are exploring the addition Users that implement this interface will then immediately benefit from the additional Cert-manager is growing quickly, and the community around it bolsters every day.<\/p>\n We\u2019d love to see new members join the community, and believe it\u2019s imperative if we If you want to get involved, take a look over our Issue board on GitHub, or drop into Want to work on community projects like cert-manager for your day job?
\nnew certificate management tool, cert-manager<\/a>, has been available for some time now.
\nIn fact, we now have over 1,000 stars on GitHub!<\/p>\n
\nIn today\u2019s modern web, securing application traffic is critical.
\ncert-manager aims to simplify management, issuance and renewal of certificates within your
\norganisation.<\/p>\n
\ntool for Kubernetes Ingress resources, has been a great success.
\nIt makes securing traffic between your users and your cluster ingress point simple.
\nOver time however, the limitations of building a controller solely around Kubernetes Ingresses
\nbecame apparent.<\/p>\n
\ngreatly increase the flexibility of configuration, debugging capabilities and also support a wider
\nrange of CAs than Let\u2019s Encrypt alone.<\/p>\n
\nsome of the new features and recent developments in the project.<\/p>\n
\nfor issuing identities to various clients in the form of signed and trusted x509 certificates.<\/p>\n
\na CA to the Kubernetes API, in the form of \u2018Issuers\u2019.<\/p>\n
\nrequests.<\/p>\n
\nthe v0.3.0 release, Hashicorp Vault!<\/p>\n
\nkind: ClusterIssuer
\nmetadata:
\nname: letsencrypt-staging
\nspec:
\nacme:
\nserver: https:\/\/acme-staging-v02.api.letsencrypt.org\/directory
\nemail: user@example.com
\nprivateKeySecretRef:
\nname: letsencrypt-private-key
\nhttp01: {}<\/p>\n
\nThese resources reference a corresponding Issuer resource in order to denote which CA they should
\nbe issued by.<\/p>\n
\nkind: Certificate
\nmetadata:
\nname: example-com
\nspec:
\nsecretName: example-com-tls
\ndnsNames:
\n– example.com
\n– www.example.com
\nissuerRef:
\nname: letsencrypt-staging
\nkind: ClusterIssuer
\nacme:
\nconfig:
\n– http01:
\ningressClass: nginx
\ndomains:
\n– example.com
\n– www.example.com<\/p>\n
\nour upcoming new release.<\/p>\n
\nthe headline features.<\/p>\nACMEv2 and wildcard certificates<\/h2>\n
\nnow supports wildcard certificates. This has been a long-awaited and requested feature,
\nand one that hasn\u2019t been possible until recently.<\/p>\n
\nswitched exclusively to use ACMEv2 as part of the v0.3 release.<\/p>\n
\nfor doing so via annotated Ingress resources (just like kube-lego!).<\/p>\n
\nalso continuing to support long-standing, legacy behaviour adopted from kube-lego.<\/p>\n
\non our GitHub page. You can request a wildcard certificate just like any other, by specifying
\n*.domain.com as one of your DNS names. See the ACME DNS validation tutorial<\/a> for more information
\non how to get started with the DNS-01 challenge.<\/p>\nVault Issuer support<\/h2>\n
\nit through the review process to the very end.<\/p>\n
\nto securely authorize cert-manager against the Vault server.<\/p>\n
\nmanager, and shows the value in providing a single clean abstraction on top of the multitude
\nof different types of CAs out there.<\/p>\nNew documentation site<\/h2>\n
\nfor brand new users, as well as in-depth details for more advanced users. All the while accounting
\nfor the varying skill levels of these users (for example, some may also be brand new to Kubernetes
\nitself!).<\/p>\n
\nto get started with cert-manager.<\/p>\n
\nThis began to cause confusion when we started versioning cert-manager more strictly, and
\nreleasing alpha\/beta release candidates.
\nIn order to handle this, and also to make it easier for users to navigate and discover the
\nvarious tutorials we do<\/em> have – we have moved our documentation over to a hosted readthedocs
\nwebsite.<\/p>\n
\nthat we have a \u2018version switcher\u2019 in the bottom left as well, if you are looking for info on the
\nlatest 0.3 release.<\/p>\n
\nor if you\u2019ve got an idea for a new tutorial please dive in and submit PRs!<\/p>\n
\nfrom our roadmap:<\/p>\nDefining Policy on Certificates<\/h2>\n
\nof any sort from any ClusterIssuer, or Issuer within the same namespace.<\/p>\n
\nCertificates, and\/or how those Certificates must be structured. This might include things such
\nas minimum and maximum durations, or a limited set of allowed DNS names.<\/p>\n
\ncontrol between all the different CAs within an organisation.
\nThis will help your organisation audit and manage who can do what.<\/p>\nAdvanced resource validation<\/h2>\n
\nacceptable values), as well as advanced \u2018mutation\u2019 of resources (e.g. applying \u2018default values\u2019).<\/p>\n
\nto be set up and run. This process can be cumbersome, and is exactly the sort of problem cert-manager
\nhas been designed to solve!<\/p>\n
\norder to provide fore-warning to developers of invalid configurations. This will involve
\na novel \u2018bootstrapping\u2019 process in order to allow for \u2018self hosted webhooks\u2019 (i.e. webhooks that
\npower cert-manager, hosted by cert-manager).<\/p>\n
\nfor these kinds of webhooks, and how you can utilise cert-manager to handle all aspects of securing them!<\/p>\nPluggable\/out-of-process Issuers<\/h2>\n
\nto their organisation.<\/p>\n
\ngiven so many different business units rely on a x509 Certificate platform.<\/p>\n
\nof a \u2018gRPC based Issuer\u2019.
\nThis is in a similar vein to CNI (Container Networking Interface) and CRI (Container Runtime Interface).
\nThe goal would be to provide a general purpose gRPC interface that anyone can implement
\nin order to sign and renew certificates.<\/p>\n
\npolicy and renewal features that cert-manager already implements.<\/p>\n
\nwant the project to survive.<\/p>\n
\n#cert-manager on the Kubernetes Slack<\/a> and say hello!<\/p>\n
\nJetstack are hiring Software Engineers, including remote (EU) roles. Check out our careers page<\/a>
\nfor more info on the roles and how to apply.<\/p>\n