Automatically provision and manage TLS certificates in Kubernetes
APACHE-2.0 License
Bot releases are visible (Hide)
Published by munnerz almost 5 years ago
This is a pre-release version of v0.12. It is considered feature complete, and has been released in order to gather feedback on the upgrade experience.
Full release notes are still TBD.
As part of this release, we have also launched a new documentation website. This website is still under construction, however the majority of the content is now available there.
You can view the documentation for v0.12 by clicking this link!
Published by munnerz about 5 years ago
The v0.11 release is a significant milestone for the cert-manager project, and
is full of new features.
We are making a number of changes to our CRDs in a backwards incompatible way,
in preparation for moving into v1beta1
and eventually v1
in the coming
releases:
certmanager.k8s.io
to cert-manager.io
certificate.spec.acme
,issuer.spec.http01
and issuer.spec.dns01
)cert-manager.io
prefix, and in some cases acme.cert-manager.io
status
subresource for submitting status updates to the API,We have also switched to using the new [CertificateRequest] based Certificate
issuance implementation, first introduced in alpha in cert-manager v0.9.
These changes enable exciting new integrations points in cert-manager, enabling
new things like:
This is a really exciting time for cert-manager, as these changes have been
made possible by refining our past decisions around API types, and they will
enable us to push ahead with many new features in the project.
With all of these great changes, there is also work to do.
The changes to our CRD resources mean that upgrading requires more manual
intervention than in previous releases.
It's recommended that you backup and completely uninstall
cert-manager
before re-installing the v0.11 release.
You will also need to manually update all your backed up cert-manager resource
types to use the new apiVersion
setting.
A table of resources and their old and new apiVersion
s:
Kind | Old apiVersion | New apiVersion |
---|---|---|
Certificate | certmanager.k8s.io/v1alpha1 |
cert-manager.io/v1alpha2 |
Issuer | certmanager.k8s.io/v1alpha1 |
cert-manager.io/v1alpha2 |
ClusterIssuer | certmanager.k8s.io/v1alpha1 |
cert-manager.io/v1alpha2 |
CertificateRequest | certmanager.k8s.io/v1alpha1 |
cert-manager.io/v1alpha2 |
Order | certmanager.k8s.io/v1alpha1 |
acme.cert-manager.io/v1alpha2 |
Challenge | certmanager.k8s.io/v1alpha1 |
acme.cert-manager.io/v1alpha2 |
You must also make sure to update all references to cert-manager in annotations to their
new prefix:
Annotation | Affected resources | New annotation |
---|---|---|
certmanager.k8s.io/acme-http01-edit-in-place | Ingress | acme.cert-manager.io/http01-edit-in-place |
certmanager.k8s.io/acme-http01-ingress-class | Ingress | acme.cert-manager.io/http01-ingress-class |
certmanager.k8s.io/issuer | Ingress | cert-manager.io/issuer |
certmanager.k8s.io/cluster-issuer | Ingress | cert-manager.io/cluster-issuer |
certmanager.k8s.io/acme-challenge-type | Ingress | REMOVED |
certmanager.k8s.io/acme-dns01-provider | Ingress | REMOVED |
certmanager.k8s.io/alt-names | Ingress, Secret | cert-manager.io/alt-names |
certmanager.k8s.io/ip-sans | Ingress, Secret | cert-manager.io/ip-sans |
certmanager.k8s.io/common-name | Ingress, Secret | cert-manager.io/common-name |
certmanager.k8s.io/issuer-name | Ingress, Secret | cert-manager.io/issuer-name |
Ingress, Secret | cert-manager.io/issuer-kind | |
Ingress, Secret | cert-manager.io/issuer-group | |
Ingress, Secret | cert-manager.io/uri-sans | |
Certificate | cert-manager.io/issue-temporary-certificate | |
CertificateRequest | cert-manager.io/private-key-secret-name | |
certmanager.k8s.io/certificate-name | CertificateRequest, Secret | cert-manager.io/certificate-name |
This release has seen code contributions from a number of people in the
community 🎉
As always, a big thank you to those opening issues, replying to issues and
helping out in the Slack channel. As well as working in other projects to help
users secure services running on Kubernetes.
Due to new policies in the upstream Kubernetes project, we have renamed the
API group from certmanager.k8s.io
to cert-manager.io
.
This is a breaking change to our API surface as mentioned above, but it
is a long time coming. The original k8s.io
suffix was used when the project
first started as there was not official guidance or information on how
ThirdPartyResources
should be structured. Now that this area of the
Kubernetes project has evolved further, we're retrospectively changing this to
conform with the new requirements.
When cert-manager first started, we defined our APIs based on what we thought
made sense for end-users.
Over time, through gathering feedback and monitoring the way users are actually
using cert-manager, we've identified some issues with our original API design.
As part of the project moving towards v1, we've identified certain areas of our
APIs that are not fit for purpose.
In order to begin the process of moving towards v1
, we first deprecated a
number of fields in our v1alpha1
API. We've now dropped these API fields
in v1alpha2
, in preparation for declaring this new API as v1beta1
in the
coming releases.
The activation of CertificateRequest
controllers are no longer behind a
feature and are now instead enabled by default. This means that when requesting
certificates using the Certificate
resource the CertificateRequest
resource
will be used as the default and only way to honour the request. The addition of
this resource introduces the ability for much greater extension points to
cert-manager, notably out-of-tree issuers, istio integrations, and experimental
tooling such as a CSI driver. You can read more about the motivation and design
of this resource in the enhancement
document.
This change should cause no disruption to how end users interact with
cert-manager, with the exception of debugging now requiring this resource to be
inspected also.
With the graduation of the CertificateRequest
resource, cert-manager now
supports out-of-tree issuers by default and treats them the same as any other
core issuer. This process is facilitated by the addition of the group
field on
issuer references inside your Certificate
and CertificateRequest
resources.
If you're interested in implementing your own out-of-tree issuer, or if there
is a provider you would like see implemented, feel free to reach out either
through a GitHub
issue
or send us a message in the #cert-manager channel on Kubernetes
Slack!
This release includes a new field URISANs
on the Certificate
resource. With
this, you can specify unique resource identifier URLs as subject alternative
names on your certificates. This addition unblocks development for an istio
integration where mTLS can be configured using cert-manager as the backend and
in turn opens up all cert-manager issuer types as valid certificate providers in
your istio PKI.
Some users may have noticed issues with the 'Order' resource not automatically
detecting changes to their configure 'solvers' on their Issuer resources.
In v0.11, we've rewritten the ACME Order handling code to:
Previously, we have issued a temporary certificate when a Certificate
resource
targeting an ACME issuer has been created. This would later be overridden once
the real signed certificate has been issued. The reason for this behaviour was
to facilitate compatibility with ingress-gce however, many users have had trouble
with this in the past and has led to lots of confusion - namely where
applications would need restarting to take on the signed certificate rather than
the temporary.
In this release, no temporary certificates will be created unless explicitly
requested. This can be done using the annotation
"cert-manager.io/issue-temporary-certificate": "true
on Certifcate
resources.
We've additionally changed the behaviour of ingress-shim to now add this new
annotation to Certificate
resources if
"acme.cert-manager.io/http01-edit-in-place"
is present on the Ingress
resource.
certmanager.k8s.io
API group to cert-manager.io
(#2096, @munnerz)URISANs
field to Certificate.Spec
resource. (#2085, @JoshVanL)hack/ci/run-dev-kind.sh
script to use the right path of cert-manager charts. (#2074, @srvaroa)Published by munnerz about 5 years ago
The v0.11.0-beta.0 is a pre-release version. It makes a number of significant changes to our CRDs, including:
certmanager.k8s.io
to cert-manager.io
certificate.spec.acme
,issuer.spec.http01
and issuer.spec.dns01
)cert-manager.io
prefix, and in some cases acme.cert-manager.io
status
subresource for submitting status updates to the API,You can read the draft release notes here: https://github.com/jetstack/cert-manager/blob/release-0.11/design/release-notes/release-0.11/draft-release-notes.md
The recommended upgrade procedure is to backup your resources and completely uninstall and reinstall cert-manager.
You can read provisional upgrade notes here: https://docs.cert-manager.io/en/release-0.11/tasks/upgrading/upgrading-0.10-0.11.html
We'd really appreciate any feedback on the upgrade procedure and any issues or tips you may run into.
There may be additional beta releases of v0.11 prior to the final v0.11 release being cut, otherwise it is due to be released mid next week.
Published by munnerz about 5 years ago
The v0.11.0-alpha.0 is a pre-release version. It makes a number of significant changes to our CRDs, including:
cert-manager.io
from certmanager.k8s.io
certificate.spec.acme
, issuer.spec.acme.http01
and issuer.spec.acme.dns01
fieldsThe recommended upgrade procedure is to backup your resources and completely uninstall and reinstall cert-manager.
You can read provisional upgrade notes here: https://github.com/jetstack/cert-manager/blob/master/docs/tasks/upgrading/upgrading-0.10-0.11.rst
We'd really appreciate any feedback on the upgrade procedure and any issues or tips you may run into.
There will be additional alpha releases of v0.11 prior to the final v0.11 release being cut.
Published by munnerz about 5 years ago
This release contains no functional changes over the recent v0.10.0 release.
The notable change is bumping the Golang version used to build cert-manager to Go 1.12.10, to address a few recent CVEs.
It's recommended all v0.10.0 users upgrade to v0.10.1 as soon as possible.
Published by munnerz about 5 years ago
The v0.10 release comes quick on the heels of v0.9. It continues the work on
the new CertificateRequest resource type, moving us towards a world where
out-of-tree Issuer types are first class citizens.
As a project, we're pushing towards a 'stable' API release and eventually, a
v1.0 release. This release, and the releases to follow over the coming months,
lay the foundation for these milestones. Keep an eye on the releases page over
the coming months for some exciting new developments!
You can get started using the new CertificateRequest controllers by enabling
the CertificateRequestControllers
feature gate - all Issuer types are now
supported, and your feedback is extremely valuable before we switch the new
implementation to be the default in v0.11!
We've also simplified the way we bootstrap TLS certificates for the 'webhook'
component. Now, instead of creating an Issuer and Certificate resource for the
webhook (requiring you to disable validation on the cert-manager namespace),
we've implemented a dedicated 'webhookbootstrap' controller which will manage
TLS assets for the webhook.
This release includes changes from:
The CertificateRequest design proposal, first implemented in v0.9, changes the
way we request certificates from Issuers in order to allow out-of-tree Issuer
types.
This required us to refactor and adapt our existing in-tree Issuer types to
follow a similar pattern.
The v0.10 release finishes this refactoring so that all Issuer types now
support the new format.
As the feature is currently still in an 'alpha' state, you must set the
issuerRef.group
field on your Certificate resources to certmanager.k8s.io
,
as well as enabling the CertificateRequestControllers
feature gate on the
controller
component of cert-manager.
In past releases, we've managed TLS for the webhook component by creating an
internal self signed and CA issuer that is used to mint serving certificates
for the apiserver to authenticate the webhook's identity.
This introduced a number of complexities in our installation process and has
caused trouble for users in the past.
In order to simplify this process and to support running a CRD conversion
webhook in future (to provide seamless migration between API versions), we've
introduced a dedicated webhookbootstrap
controller that relies on flags and
Secret resources in order to configure TLS for the webhook.
This will mean easier installation as well as future-proofing for our upcoming
plans in future releases.
In order to support a more diverse set of applications, including apps that
require client-auth certificates, a new field keyUsages
has been added which
accepts a list of usages that must be present on a Certificate.
These will be automatically added when certificates are issued, just like any
other field on the Certificate.
Thanks to Stuart Warren from Ocado for this change!
Over the last few releases, we've been making a number of significant changes
to our API types (i.e. moving ACME configuration from Certificate resources
onto the Issuer resource). This has involved deprecating some old API fields.
In a future release, we'll be removing these deprecated fields altogether,
requiring users to update their manifests to utilise the new way to specify
configuration.
A number of steps have been taken in our own codebase to support this change,
and in a future release, you'll be required to update all your manifests for
this new format. Future API revisions (e.g. v1beta1 and v1) will be
automatically converted using a Kubernetes conversion webhook (available in
beta from Kubernetes 1.15 onwards).
No special actions are required as part of this release.
Published by JoshVanL about 5 years ago
Published by munnerz about 5 years ago
The v0.9 release is one of our biggest yet, packed with new features and bug
fixes!
The introduction of the new CertificateRequest resource type is significant as
it is a step towards where we want to be for 1.0, defining an API specification
for Certificates and allowing anyone to implement their own issuers and CAs as
first class citizens.
This release includes changes from:
A new resource has been introduced - CertificateRequest
- that is used to
request certificates using a raw x509 certificate signing request. This resource
is not typically used by humans but rather by other controllers or services. For
example, the Certificate
controller will now create a CertificateRequest
resource to resolve its own Spec.
Controllers to resolve CertificateRequest
s are currently disabled by default
and enabled via the feature gate CertificateRequestControllers
. This feature
is currently in Alpha and only the CA issuer has been implemented.
This resource is going to enable out of tree, external issuer controllers to
resolve requests. Other issuer implementations and details on how to develop an
out of tree issuer will follow in later releases. You can read more on the
motivations and road map in the enhancement proposal or how this resource is
used in the docs.
A list of DNS zones can now be added to the ACME challenge solver selector. The
most specific DNS zone match specified here will take precedence over other DNS
zone matches, so a solver specifying sys.example.com
will be selected over one
specifying example.com
for the domain www.sys.example.com
. If multiple
solvers match with the same dnsZones value, the solver with the most matching
labels in matchLabels will be selected. If neither has more matches, the solver
defined earlier in the list will be selected.
Cert-manager now exposes Prometheus metrics on Certificate ready statuses as
certmanager_certificate_ready_status
. This is useful for monitoring
Certificate resources to ensure they have a Ready=True
status.
Support has been added to include a Prometheus ServiceMonitor for cert-manager
in the helm chart. This enables monitoring of cert-manager when in conjunction
with the Prometheus Operator.
This is disabled by default but can be enabled via the helm configuration.
We have now switched to use the new POST-as-GET feature that was introduced
into the latest version of the ACME spec a few months ago.
If you are running your own ACME server, please ensure it supports POST-as-GET
as we no longer supported the old behaviour.
The ACME Solver Pod Spec now exposes a template that can be used to change
metadata about that pod. Currently, a template will expose labels, annotations,
node selector, tolerations, and affinity. This is useful when running
cert-manager in multi-arch clusters, or when you run workloads across different
types of nodes and need to restrict where the acmesolver pod runs.
Common names with a character length of over 63 will be rejected during
validation. This is due to the upper limit being detailed in RFC 5280.
For each container, cert-manager ships with the base image
'gcr.io/distroless/static' which is a minimal image that includes no binaries.
Users who want to debug from within the cert-manager pod will need to attach an
additional container with their debug utilities to the pod's namespace.
CSRs in Order resources have previously been incorrectly DER encoded due to an
error in implementation. This has now been corrected to PEM encoding. Current
orders that were created with a previous version of cert-manager will fail to
validate and so will be recreated. This should resume the order normally.
secretName
(#1689, @cheukwing)--feature-gates=IssueTemporaryCertificate=false
(#1764, @gordonbondon)nodeSelector
and tolerations
in podTemplate.spec
(#1803, @cheukwing)spec.acme.email
field in Issuers (#1763, @cheukwing)issuewild
tag when verifying CAA (#1777, @cheukwing)group
to issuerRef
in CertificateRequest
resources to distinguish resource ownership of incoming CertificateRequests so enabling full external issuer support. (#1860, @JoshVanL)ControllerSyncCallCount
prometheus metric to count sync calls from each controller (#1692, @cheukwing)Published by JoshVanL over 5 years ago
Release notes TBD, view draft here
Published by munnerz over 5 years ago
Published by munnerz over 5 years ago
Published by munnerz over 5 years ago
Following on from the v0.7.x releases and a series of pre-release candidates,
cert-manager v0.8.0 is available at last!
This release packs in a tonne of stability improvements, as well as a whole load
of new features 😀
As part of this release, we're updating our API format in order to better
support the 1.0 release, which we hope to reach within the next few months.
This has been accomplished in a backwards-compatible for now, to make the
upgrade process easier, especially for users that manage large numbers of
certificate resources.
As well as the new release, we've also finally created a project logo!
For those of you who are attending KubeCon EU, we'll be handing out stickers
at the Jetstack booth from tomorrow onwards!
The deployment manifests have now moved from being a part of our GitHub
repository and are now published alongside each image tag. Please double
check the installation guide for more information on where the manifests
can now be found. This change does not affect the Helm chart!
As part of stabilising our API surface, we've made a change to the way
you configure your ACME based certificates.
Instead of Certificate resources containing an extra certificate.spec.acme
field, which is only relevant for ACME certificates, the configuration has now
moved over to the Issuer resource instead. More details on this change can be
found in the upgrade notes.
In order to make it easier for users to run cert-manager on platforms other
than Kubernetes, we've improved our OpenShift support, including an official
installation guide for users of OpenShift.
If you use OpenShift in your organisation, check out the getting started section
for more information on how to get up and running!
Over the last year and a half, we've had more than 15 pull requests to add new
ACME DNS01 providers to our codebase. It's been brilliant to see such vibrant
community involvement, however it's become infeasible for us to continue to
accept, test and maintain such a rapidly growing matrix of providers.
As a result, we've put together a new 'webhook' DNS01 solver type.
This allows you to create and install your own DNS01 providers without having
to make changes in cert-manager itself.
You can see an example repository to get started building your own over in the
cert-manager-webhook-example repo on GitHub.
This is a new and experimental feature, however we're excited to see the community
move to this new model of extending cert-manager.
As the project has grown, we've also increased the verbosity and frequency of our log messages.
Over time, this has become difficult to manage and work with, and so with the v0.8 release
we have begun the process of switching over our codebase to structured logging.
This should make it far easier to index, search and grep through log messages that cert-manager
emits.
Your feedback here is really valuable, so please open issues and comment on Slack if you
have any issues!
lastTransitionTime
set to null
(#1628, @munnerz)issuer.spec.acme.solvers
field that replaces certificate.spec.acme'
in order to make all certificate resources portable between issuer types. The previously syntax is still supported to allow easy migration to the new configuration format. (#1450, @munnerz)--feature-gates=ValidateCAA=true
option to enable it (#1585, @munnerz)hostedZoneName
to be specified. Uses discovered DNS zone name instead. (#1466, @logicfox)Published by munnerz over 5 years ago
This should be the final pre-GA release of v0.8, pending no new issues being raised this week.
Manual testing and feedback from users on v0.8.0-alpha.0
showed consistent, successful results barring a fix that was made in #1620.
As part of this release, we will no longer be publishing 'static deployment manifests' as part of the repository. Instead, these will be published via GitHub Releases.
Documentation changes will be made this week to account for the new options, including updated deployment instructions for users of the 'static deployment manifests'.
Thanks to all those that have tried the v0.8 pre-releases 😄
lastTransitionTime
set to null
(#1628, @munnerz)Published by munnerz over 5 years ago
This is a bugfix release for v0.7 and it is recommended all v0.7 users upgrade as soon as possible.
Notably, the newly introduced CAA record check has been disabled by default whilst we investigate issues with certain DNS resolvers that could cause the self-check to fail despite having passed in previous versions.
The new CAA check behaviour can be re-enabled by setting the --feature-gates=ValidateCAA=true
flag on the cert-manager controller pod (or via --set extraArgs='[--feature-gates=ValidateCAA=true]'
flag when running helm install
).
--feature-gates=ValidateCAA=true
option to enable it (#1585, @munnerz)Published by munnerz over 5 years ago
Full release notes TBC.
issuer.spec.acme.solvers
field that replaces certificate.spec.acme'
in order to make all certificate resources portable between issuer types. The previously syntax is still supported to allow easy migration to the new configuration format. (#1450, @munnerz)--feature-gates=ValidateCAA=true
option to enable it (#1585, @munnerz)hostedZoneName
to be specified. Uses discovered DNS zone name instead. (#1466, @logicfox)Published by munnerz over 5 years ago
This is a patch release that fixes a number of important issues that could cause ACME validations to fail in certain DNS configurations, as well as rare issues when upgrading from v0.6.x.
Published by munnerz over 5 years ago
The Helm chart rbac.create
option has moved to be global.rbac.create
.
Users of the Helm chart will need to update their install overrides to use
the new format.
The Helm chart has now moved to be hosted on charts.jetstack.io
, and
exposed via the Helm Hub. This allows us to make
and test changes to the Helm chart more easily, and better manage versioning.
This release introduces a new issuer type for Venafi Cloud and Venafi Trust
Protection Platform.
The Venafi adapter will be built out over the coming months to improve the
integration and expose more of the Venafi platform's advanced functionality.
This release introduces support for injecting CA bundles into Kubernetes
{Validating,Mutating}WebhookConfiguration & APIService resources.
You can utilise the new controller by adding the certmanager.k8s.io/inject-ca-from
annotation to your webhook and APIService resources.
This was needed in order to improve our own deployment of the 'webhook'
component as part of this release.
The v0.6 release utilised an additional ca-sync
CronJob resource that allowed
us to secure the webhook component automatically using cert-manager itself.
Thanks to the new cainjector controller described above, we have now removed
this CronJob altogether in favour of using the far more reliable controller.
Support for ARM was adding as part of this release (#1212). We do not currently
have automated testing using ARM platforms, so this feature is still marked
experimental.
To utilise the new ARM support, you'll need to update your manifests and append
the architecture to the image name (i.e. quay.io/jetstack/cert-manager-controller-arm64:v0.7.0
).
The introduction of the Challenge resource in the last release has allowed us
to provide better means for debugging failures.
In the v0.7.0 release, if a self check or ACME validation is failing for some
reason, this information will be displayed when running kubectl get
and
kubectl describe
.
Published by munnerz over 5 years ago
This patch release of cert-manager resolves issues when running the webhook component on Amazon EKS.
You can find more information in #1220
Published by munnerz over 5 years ago