Automatically provision and manage TLS certificates in Kubernetes
APACHE-2.0 License
Bot releases are hidden (Show)
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
Published by munnerz over 5 years ago
The long-awaited v0.6 release is here! This release includes a huge number of improvements, bug fixes and new features.
We've made a big focus on the ACME implementation, as well as improving the general user-experience when requesting certificates.
We've exposed new x509 certificate fields via the Certificate resource type, as well as improving support for these options across all Issuer types.
As of the v0.6 release being cut, we've also reached a huge 99 code contributors! This is incredible to see, and we're thankful to all those who have contributed in all forms over the last couple of years!
Read on to get some of the highlights, as well as the full list of note-worthy changes below!
This release of cert-manager refactors how ACME certificates are handled significantly.
This should result in:
This is largely an internal change, but with far reaching benefits.
For more details, check out the details in the pull request (#788).
We are keen to hear feedback on this new design, so please create issues including the /area provider-acme
text in order to report feedback/problems.
After extensive testing, we've found in the most extreme cases a 100x reduction in ACME API client calls.
This is a massive difference, and helps reduce the load that instances of cert-manager put on services like Let's Encrypt.
As a result, we strongly recommend all users upgrade to the v0.6 release as soon as possible!
In order to support the API client testing above, we've also added support for Prometheus metrics into our ACME client.
This means you can now start instrumenting cert-manager's own usage of ACME APIs, in order to detect issues and understand behaviour before it becomes a problem.
The metrics are broken down by path, status code and a number of other labels.
In order to provide a better experience out of the box, we've now enabled the validating webhook component by default.
This means that when you submit resources to the API server, they will be checked for misconfigurations before they are persisted to the API, meaning configuration errors are surfaced immediately, and in some cases alongside steps that can be taken to remediate the errors.
It's now possible to create ECDSA private keys when issuing certificates from ACME servers. You can configure the key type and key size using certificate.spec.keyAlgorithm
and certificate.spec.keySize
respectively.
As part of our validation for this release, we've been able to test cert-manager in larger deployment configurations.
This includes running with an ACME issuer with 6k+ domain names, showing that our client usage remains sensible and cert-manager itself does not begin to strain.
Off the back of this scale testing, we've also got numerous scale-related improvements triaged for the next minor release, v0.7.
There is only one PR that changes previous behaviour in this release.
Between v0.4.0 and v0.5.0, we introduced support for following CNAME records when presenting DNS01 challenges. This inadvertently broke DNS01 challenge solving when a user used a CNAME record at the route of their DNS zone (i.e. on Route53 when using an Amazon ELB).
This change reverts the default behaviour to support this kind of setup without additional changes, and instead introduces a new cnameStrategy
field on ACME Issuer resources. You can set this field to Follow
to restore the behaviour introduced in v0.5.0.
This note only affects the ACME Issuer type.
canary
builds (#997) (#1021, @Nalum)--namespace
option to limit scope to a single namespace (#1188, @kragniz)kubectl get
(#1194, @munnerz)nameserver
key has value with no port (#908, @splashx)ca
Issuer. This will then be propagated to generated certificates. (#1077, @mikebryant)Published by munnerz almost 6 years ago
--namespace
option to limit scope to a single namespace (#1188, @kragniz)kubectl get
(#1194, @munnerz)ca
Issuer. This will then be propagated to generated certificates. (#1077, @mikebryant)Published by munnerz almost 6 years ago
These release notes are a pre-release and are subject to change before the release of v0.6.0
--namespace
option to limit scope to a single namespace (#1188, @kragniz)kubectl get
(#1194, @munnerz)ca
Issuer. This will then be propagated to generated certificates. (#1077, @mikebryant)Published by munnerz almost 6 years ago
These release notes are a pre-release and are subject to change before the release of v0.6.0
This release of cert-manager refactors how ACME certificates are handled significantly.
This should result in:
This is largely an internal change, but with far reaching benefits.
For more details, check out the details in the pull request (#788).
We are keen to hear feedback on this new design, so please create issues including the /area provider-acme
text in order to report feedback/problems.
It's now possible to create ECDSA private keys when issuing certificates
from ACME servers. You can configure the key type and key size using certificate.spec.keyAlgorithm
and certificate.spec.keySize
respectively.
There is only one PR that changes previous behaviour in this release.
Between v0.4.0 and v0.5.0, we introduced support for following CNAME records when presenting DNS01 challenges. This inadvertently broke DNS01 challenge solving when a user used a CNAME record at the route of their DNS zone (i.e. on Route53 when using an Amazon ELB).
This change reverts the default behaviour to support this kind of setup without additional changes, and instead introduces a new cnameStrategy
field on ACME Issuer resources. You can set this field to Follow
to restore the behaviour introduced in v0.5.0.
This note only affects the ACME Issuer type.
canary
builds (#997) (#1021, @Nalum)Introduce ACME 'Order' and 'Challenge' resource types & re-implement ACME Issuer to be completely driven by CRDs (#788, @munnerz)
ACTION REQUIRED: Fix ACME issues relating to wildcard CNAME records and add a 'cnameStrategy' field to the ACME Issuer DNS01 provider config. (#1136, @munnerz)
Added certmanager.k8s.io/acme-http01-ingress-class annotation to ingress-shim (#1006, @kinolaev)
Make http01 solver serviceType configurable, so one can use ClusterIP instead of the previously hardcoded type NodePort. NodePort still remains as default. (#924, @arnisoph)
Revised Cert Issuer Docs for DNS01 challenge and added a doc for AzureDNS (#915, @damienwebdev)
Make http01 solver pod resource request/limits configurable (#923, @arnisoph)
Allow ECDSA keys for ACME certificates (#937, @acoshift)
RFC2136 provider: fixes a minor bug where dns01 nameserver
key has value with no port (#908, @splashx)
Add DigitalOcean DNS Provider (#972, @aslafy-z)
Published by munnerz almost 6 years ago
Two releases in one day!
This release contains a single additional patch over v0.5.1.
In cases where you have defined Ingress resources with multiple different hostnames, that only enable TLS for a subset of those hostnames - if ingress-shim is enabled for these Ingress resources, the hosts that did not have TLS enabled would be removed from the Ingress resource.
Published by munnerz almost 6 years ago
This is a bugfix release for the v0.5 release series
It resolves an issue relating to our 'retry policies' when processing an Issuer resource fails.
In some edge cases, a misconfigured client will attempt to re-verify ACME accounts at a high rate, potentially causing issues for the ACME server.
All users should upgrade to this release as soon as possible - there have been no significant or breaking changes as this is a patch release!
Published by munnerz about 6 years ago
Following the v0.4.0 release, we have now added a 'validating webhook' for our API resources. This will help prevent invalid configurations being submitted to the API server.
This feature is disabled by default.
Information on enabling the new webhook component can be found in the Resource Validation Webhook document.
A number of new fields have been added to the Certificate resource type:
New fields like this make cert-manager more useful for applications beyond just securing Ingress, as well as allowing users to continue meeting their security requirements for x509 certificates.
This release includes two new DNS provides for the ACME Issuer:
These additions should help more users begin using cert-manager with their chosen DNS provider, without having to delegate to an alternate provider that is supported 🎉
Published by munnerz about 6 years ago
This is a bugfix release for the v0.4 release series.
It fixes a number of issues relating to the ACME Issuer. Notably, it fixes a bug that could cause ACME orders to be handled when they are in the 'valid' state (i.e. already issued).
It is advised all users of the v0.4 series upgrade to v0.4.1 as soon as possible.
Published by munnerz over 6 years ago
This is the next feature release of cert-manager, containing a number of additions
that have been in the works for a while now.
As you will notice from the release notes below, we are seeing a lot more community
contributions to the project which is brilliant! 😄
A massive thank you to everyone involved in making this release a reality.
We have moved to a more regular minor-release schedule, and aim to cut new feature
releases monthly. That means the next minor release (v0.5) is scheduled for
around the 11th August.
A common pain point for users has been around submitting invalid resources to the
API, which cannot be handled or processed.
Other Kubernetes API types handle this well by applying 'validation' before the
resource is persisted or operated upon, and up until now we have not supported this.
When submitting your resources to the Kubernetes apiserver, they will now be validated
and if invalid, cert-manager will inform you of why and how they are invalid and
suspend processing of that resource.
In the next release, this validation will be turned into a 'ValidatingWebhookConfiguration'
which will allow us to prevent these resources being persisted into the API in
the first place, similar to all other Kubernetes resource types.
Due to some limitations with the current release of Helm, we have been unable to
support this webhook operation mode in the v0.4 release of cert-manager.
However, releasing validation this way allows us to pilot the new validation rules
we have in place and it allows you to get started with it immediately!
Regularly, users ask us "what can I specify on my resources". In the past, we have
had to recommend users check out our source code (namely types.go
) in order to
find out what can and cannot be specified.
Digging through source code is no longer required! As part of our documentation
publishing process, we now generate reference API documentation (similar to the
upstream Kubernetes project!). This is available under the
'Reference documentation -> API documentation' section of our docs site!
A number of users have noticed that when running cert-manager with DNS01 challenges
in split-horizon DNS environments (using the ACME issuer), the self check stage
of the validation process failed as the 'internal' DNS resolvers were used to
check for challenge record propagation.
We have added a new flag, --dns01-self-check-nameservers
, that allows users to specify
custom recursive DNS servers to use for performing DNS01 self checks.
In these environments, this flag can be set to some external nameserver list that
will be used for DNS01 resolution, e.g. 8.8.8.8:53,8.8.4.4:53
.
We recently merged support for 'self signed' issuers. This allows users to create
the basis for a completely cert-manager managed PKI by 'self signing' certificates.
This can be useful when debugging, or once cert-manager also supports setting the
isCA
bit on a Certificate, for creating a self signed root CA!
Read up on how to get started with this new issuer type in the documentation.
ACME http01 validation is no longer attempted using an
Issuer/ClusterIssuer with no ACME http01 config. Note that the minimal
http01: {}
config IS sufficient.
If you rely on ACME http01 validation, you should check your issuers to make
sure http01 validation is explicitly enabled as in previous release, this was
not verified!
--dns01-nameservers
flag for setting nameservers for DNS01 check (#710, @kragniz)certmanager.k8s.io/certificate-name
label to secrets. (#719, @kragniz)--controllers=issuers,clusterissuers,certificates
(#717, @kragniz)Published by munnerz over 6 years ago
Documentation | Upgrading guide
This is a bugfix release containing a critical patch for the ACME Issuer implementation.
Let's Encrypt recently made a change to their API to bring it in-line with the latest ACME draft spec, which has caused cert-manager to fail to obtain Certificates in some cases. More information can be found on the Let's Encrypt forum.
It is advised that all users of v0.3.x upgrade to this release immediately, as without the changes included in this release, certificate renewal will not be successful.
As this is a patch release, there have been no breaking changes. Please do not hesitate to upgrade your deployments!
Published by munnerz over 6 years ago
Documentation | Upgrading guide
This is a bugfix release with two important changes to reduce ACME server API usage, and fix a bug with renewing ACME certificates.
It is advised that all users of v0.3.0 upgrade to this release immediately.
Published by munnerz over 6 years ago
Documentation | Upgrading guide
This is a big feature filled release of cert-manager, and the first since moving to a
more frequent release model.
There's been a huge uptick in community contributions to the project, and this release
comprises the combined effort of 38 code contributors and hundreds of users reporting
issues, feature requests and bug reports!
There's quite a few big headline points, so we'll get straight in:
This release of cert-manager brings the long-awaited ACMEv2 support, and with it, Let's Encrypt
wildcard certificates!
This allows you to request certificates for wildcard domains, e.g. *.example.com, which can be used
to secure many different subdomains of your domain!
The introduction of ACMEv2 is a breaking change. Please read the notes below in the Action Required
section for details on how to handle your existing ACME Issuers whilst upgrading from v0.2.x.
This release introduces initial support for Hashicorp Vault as an Issuer backend! Initially, this includes support for authenticating via AppRole and static token.
The support for this Issuer is classed as 'alpha' - feedback is invaluable at this stage of development, so we are getting it out there in a tagged release to gather usage info.
More information on configuring a Vault Issuer can be found in the Vault Issuer docs.
Whilst this note applies to the v0.2.x release series also, it is worth noting.
We have now moved to readthedocs.io and reStructuredText for our documentation.
This should hopefully make it easier for external collaborators to make quick edits
to our documentation, and should provide more structure.
We'd like to take the time to thank all those that have opened issues or opened pull requests against
our documentation - it's a difficult thing to get right, but it's imperative our documentation is
clear for new users adopting the project.
When cert-manager was first released, only CloudDNS and Cloudflare DNS01 providers were
supported when solving ACME challenges.
As new users, each using their own DNS providers, have adopted the project; there has been
a flurry of contributions adding support for the variety of providers out there.
With this release, we support the following DNS providers when solving ACME DNS01 challenges:
There are pull requests in flight to add support for:
Please check the 'upgrading from 0.2 to 0.3' guide in the Administrative Tasks section of the docs here before upgrading.
Supporting resources for ClusterIssuer's (e.g. signing CA certificates, or ACME account private keys) will now be stored in the same namespace as cert-manager, instead of kube-system in previous versions (#329, @munnerz):
Action required: you will need to ensure to properly manually migrate these referenced resources across into the deployment namespace of cert-manager, else cert-manager may not be able to find account private keys or signing CA certificates.
Use ConfigMaps for leader election (#327, @mikebryant):
Action required: Before upgrading, scale the cert-manager Deployment to 0, to avoid two controllers attempting to operate on the same resources
Remove support for ACMEv1 in favour of ACMEv2 (#309, @munnerz):
Action required: As this release drops support for ACMEv1, all Issuer resources that use ACMEv1 endpoints (e.g. existing Let's Encrypt Issuers) will need updating to use equivalent ACMEv2 endpoints. (TODO: link to docs guide)
Remove ingress-shim and link it into cert-manager itself (#502, @munnerz)
Action required: You must change your 'helm install' command to use the new --ingressShim.defaultIssuerName, --ingressShim.defaultIssuerKind options when upgrading as --ingressShim.extraArgs has been removed.
Add certmanager.k8s.io/acme-http01-edit-in-place
annotation and change ingress-shim to set 'ingressClass' on ACME Certificate resources by default. (#493, @munnerz)
Action required: This is a potentially breaking change for users of ingress controllers that map a single IP address to a single Ingress resource, such as the GCE ingress controller. These users will need to add the following annotation to their ingress: certmanager.k8s.io/acme-http01-edit-in-place: "true"
.
--issuer-ambient-credentials
and --cluster-issuer-ambient-credentials
flags on the cert-manager controller. (#363, @euank)kubernetes.io/tls-acme
annotation if the value of that annotation is true. (#325, @wmedlar)cert
and certs
. This is configurable in the Helm Chart with certificateResourceShortNames
. (#312, @Mikulas)Published by munnerz over 6 years ago
This is a bugfix release which fixes bugs in the way rate limits were handled within the Certificate control loop. This could cause failing authorizations to be retried in quick succession.
It is recommended that all users of v0.2.x upgrade to this release as soon as possible.
Published by munnerz over 6 years ago
This is an alpha release of cert-manager. It is subject to change in breaking ways
and should only be used for testing the latest features of cert-manager in order to
provide feedback ahead of a non-alpha release.
This release follows on from the alpha.1 release earlier this month.
Notably, ingress-shim is now no longer a standalone binary, and is instead linked into the main cert-manager-controller container. This should see a reduction in memory consumption, as well as simplified deployment and operations when inspecting cert-manager itself.
We have also changed the default behaviour of ingress-shim (or now, cert-manager), to set the ingressClass
field instead of ingress
on Certificate resources it creates. This should enable better compatibility with ingress controllers like nginx. For more information on the reasons for this change, see #235.
In order to continue to support users using ingress controllers that bind a single IP address to a single Ingress resource (such as the gce ingress controller), we have added the new certmanager.k8s.io/acme-http01-edit-in-place
annotation that can be added to your Ingress resource. When set, cert-manager will set the ingress
field on the Certificate resource it generates (similar to the behaviour in previous releases).
ACTION REQUIRED: Remove ingress-shim and link it into cert-manager itself. You must change your 'helm install' command to use the new --ingressShim.defaultIssuerName
, --ingressShim.defaultIssuerKind
options when upgrading as --ingressShim.extraArgs
has been removed. (#502, @munnerz)
ACTION REQUIRED: Add certmanager.k8s.io/acme-http01-edit-in-place
annotation and change ingress-shim to set 'ingressClass' on ACME Certificate resources by default. This is a potentially breaking change for users of ingress controllers that map a single IP address to a single Ingress resource, such as the GCE ingress controller. These users will need to add the following annotation to their ingress: certmanager.k8s.io/acme-http01-edit-in-place: "true"
. (#493, @munnerz)