Adds release notes from to tree

Signed-off-by: JoshVanL <vleeuwenjoshua@gmail.com>
This commit is contained in:
JoshVanL
2019-07-15 11:58:50 +01:00
parent e43a39763e
commit cecf1cd451
8 changed files with 577 additions and 0 deletions
@@ -0,0 +1,21 @@
This is the first release of cert-manager. It is currently still not in a production ready state, and features are subject to change.
Notable features:
- *Automated certificate renewal*
- *ACME DNS-01 challenge mechanism*
- CloudDNS
- Route53
- Cloudflare
- *ACME HTTP-01 challenge mechanism*
- Should be compatible with all ingress controllers following ingress spec (GCE & nginx tested)
- *Simple CA based issuance*
- Create an Issuer that references a Secret resource containing a signing keypair, and issue/renew certificates from that.
- *Cluster-wide issuers (aka ClusterIssuer)*
- *Backed by CRDs*
- Events logged to the Kubernetes API
- Status block utilised to store additional state about resources
Please check the [README(https://github.com/jetstack-experimental/cert-manager) for a quick-start guide.
We really value any feedback and contributions to the project. If you'd like to get involved, please open some issues, comment or pick something up and get started!
@@ -0,0 +1,14 @@
## Changelog since v0.1.0
### Action Required
- Move to 'jetstack' organisation. Action required: this will require updating your existing deployments to point to the new image repository, as new tags will not be pushed to the old 'jetstackexperimental/cert-manager-controllerrepository. Ahelm upgrade` should take care of this. (#145, @munnerz)
- Set the Kubernetes secret type to TLS. Action required: this will cause renewals of existing certificates to fail. You must delete certificates that have been previously produced by cert-manager else cert-manager may enter a renewal loop when saving the new certificates. Alternatively, you may specify a new secret to store your certificate in and manually update your ingress resource/applications to reference the new secret. (#172, @munnerz)
### Other notable changes
- No longer support ClusterIssuer resources when cert-manager is running with --namespace flag set (#179, @munnerz)
- Overcome 'registration already exists for provider key' errors in ACME provider by auto-detecting lost ACME registration URIs (#171, @munnerz)
- Fix checking for invalid data in issuer secrets (#170, @munnerz)
- Fix bug in ACME HTTP01 solver causing self-check to return true before paths have propagated (#166, @munnerz)
- Fix panic if the secret named in an ACME issuer exists but contains invalid data (or no data) (#165, @munnerz)
- Ensure 5 consecutive HTTP01 self-checks pass before issuing ACME certificate (#156, @munnerz)
- Fix race condition in ACME HTTP01 solver when validating multiple domains (#155, @munnerz)
- Consistently use glog throughout (#126, @munnerz)
@@ -0,0 +1,124 @@
# Highlights
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:
## ACMEv2 and Let's Encrypt wildcard certificates
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.
## Alpha support for Hashicorp Vault
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.
## readthedocs.io documentation site
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.
## New ACME DNS01 providers
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:
- Akamai FastDNS (#322, @twz123)
- Amazon Route53
- Azure DNS (#246, @mwieczorek)
- Cloudflare
- Google CloudDNS
There are pull requests in flight to add support for:
- DNSPod (#486, @hemslo)
- DNSimple (#483, @marc-sensenich)
- DigitalOcean (#345, @dl00)
- INWX (#336, @steigr)
- RFC2136 (#245, @simonfuhrer)
# Changelog
## Action Required
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".
## Other notable changes
### ACME Issuer
- Add ACME DNS-01 provider for Akamai FastDNS (#322, @twz123)
- Add a meaningful user agent to the ACME client to help diagnosing abusive traffic patterns (#422, @jsha)
- Issuers using the AWS Route53 solver may attempt to find credentials using the environment, EC2 IAM Role, and other sources available to the cert-manager controller. This behavior is on by default for cluster issuers and off by default for issuers. This behavior may be enabled or disabled for all issuers or cluster issuers using the --issuer-ambient-credentials and --cluster-issuer-ambient-credentials flags on the cert-manager controller. (#363, @euank)
- Add limits to http validation pod (#408, @kragniz)
- The ACME dns01 solver now trims excess whitespace from AWS credentials (#391, @euank)
- ACME DNS-01 challenge mechanism for Azure DNS (#246, @mwieczorek)
- Fix panic when ACME server returns an error other than HTTP Status Conflict during registration (#237, @munnerz)
### CA Issuer
- Add the Key Encipherment purpose to CA Issuer generated certificates (#488, @bradleybluebean)
- Bundle CA certificate with issued certificates (#317, @radhus)
### Vault Issuer
- Add experimental support for Hashicorp Vault issuers (#292, @vdesjardins)
- ingress-shim
- ingress-shim now reconfigures certificates (#386, @kragniz)
- ingress-shim will only sync Ingress resources with kubernetes.io/tls-acme annotation if the value of that annotation is true. (#325, @wmedlar)
### Docs
- Rewrite documentation and publish on readthedocs (#428, @munnerz)
- Document the minimum necessary permissions for using cert-manager with Route53 (#359, @wmedlar)
- Improve deployment documentation (#264, @munnerz)
### Helm
- Add clusterResourceNamespace option to Helm chart (#547, @munnerz)
- Enhance Helm chart in-line with best practices (#229, @unguiculus):
- Add support for node affinity and tolerations in Helm chart (#350, @kiall)
- Add podAnnotations to Helm chart (#387, @etiennetremel)
- Add Certificate CRD shortnames cert and certs. This is configurable in the Helm Chart with certificateResourceShortNames. (#312, @Mikulas)
- Remove default resource requests in Helm chart. Improve post-deployment informational messages. (#290, @munnerz)
- End-to-end testing now covers the helm chart for cert-manager on Kubernetes 1.7-1.9 (#216, @munnerz)
### Other
- Produce a single static manifest instead of a directory when generating deployment manifests (#574, @munnerz)
- Use cert-manager deployment namespace by default for leader election (#548, @munnerz)
- Removed --namespace flag (#433, @kragniz)
- Run cert-manager container as a non root user (#415, @tettaji)
- TLS secrets are now annotated with information about the certificate (#388, @kragniz)
- The static deployment manifests now automatically deploy into the 'cert-manager' namespace by default (#330, @munnerz)
- Rename Event types to be prefixed 'Err' instead of 'Error' for brevity (#332, @munnerz)
- Clearer event logging when issuing a certificate for the first time (#331, @munnerz)
- Provide static deployment manifests as an alternative to a Helm chart based deployment (#276, @munnerz)
- Update existing secrets instead of replacing in order to preserve annotations/labels (#221, @munnerz)
- Update to Go 1.9 (#200, @euank)
### Bugfixes
- Fix a race condition in the package responsible for scheduling renewals (#218, @munnerz)
- Fix a bug that caused ACME certificates to not be automatically renewed (#215, @munnerz)
- Fix a bug in checking certificate validity and improve validation of dnsNames and commonName (#183, @munnerz)
- Fix bugs when checking validity of certificate resources (#184, @munnerz)
@@ -0,0 +1,94 @@
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! smile
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.
# Highlights
## Resource validation for Issuers, ClusterIssuers and Certificates
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!
## Added reference documentation for API types
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!
## Better support for 'split horizon' DNS environments with ACME DNS01 challenges
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.
## Self-signed Issuers
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.
# Changelog
## Action Required
- Check the acme issuer has the 'HTTP01' challenge type configured if in use. (#629, @groner)
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!
## Other notable changes
### ACME Issuer
- Add --dns01-nameservers flag for setting nameservers for DNS01 check (#710, @kragniz)
- Fix bugs affecting eTLD and CNAMEs during DNS zone resolution (#582, @ThatWasBrilliant)
- Run acmesolver container as non-root user (#585, @klausenbusk)
- Support for ACME HTTP01 validations when using istio-ingress with a mTLS enabled mesh (#622, @munnerz)
### Vault Issuer
- Configurable Vault appRole authentication path using the attribute is spec.vault.auth.authPath in the issuer. (#612, @vdesjardins)
### Self-signed Issuer
- Add 'self signed' Issuer type (#637, @munnerz)
### Docs
- Add reference documentation for API types (#644, @munnerz)
### Helm
- Added configuration variables to set http_proxy, https_proxy and no_proxy environment variables in Helm chart. (#680, @fllaca)
- added option to set additional environment variable values to the helm chart (#556, @nazarewk)
### Other
- Add certmanager.k8s.io/certificate-name label to secrets. (#719, @kragniz)
- Add resource validation at start of sync loops, and mark resources as not Ready when invalid (#682, @munnerz)
- To disable ingress-shim, you can now set this flag: --controllers=issuers,clusterissuers,certificates (#717, @kragniz)
@@ -0,0 +1,47 @@
# Highlights
## Resource validation webhook
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.
## New Certificate options
A number of new fields have been added to the Certificate resource type:
- keyAlgorithm - support alternative private key algorithms (e.g. rsa or ecdsa) for generated certificates.
- keySize - allow specifying an alternative key bit size
- isCA - allows generating certificates with the 'signing' usage set
- organization - allows specifying values for the 'O' field of Certificates (for supported providers)
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.
## New ACME DNS providers
This release includes two new DNS provides for the ACME Issuer:
- acme-dns
- RFC2136
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 tada
# Changelog
## General
- Add renew-before-expiry-duration option to configure how long before expiration a certificate should be attempted to be renewed (#801, @munnerz)
- Add validation webhooks for API types (#478, @munnerz)
- Add extended issuer-specific validation to certificates at runtime (#761, @kragniz)
## API changes
- Adds new fields: "keyAlgorithm", "keySize" onto CertificateSpec to allow specifying algorithm (rsa, ecdsa) and key size to use when generating TLS keys (#722, @badie)
- Add isCA field to Certificates (#658, @munnerz)
- Add "organization" field to certificate objects (#838, @Queuecumber)
## CA Issuer
- Don't bundle the CA certificate when using the self signed issuer (#811, @munnerz)
## ACME
- Fix issue that could cause Certificates to fail renewal (#800, @munnerz)
- Add acme-dns as a dns01 provider (#787, @Queuecumber)
- [jjo] fix panic from acmedns.go constructor failure (#858, @jjo)
- Fix cloudflare provider failing on cleanup if no record is found (#849, @frankh)
- Fixed Route53 cleanup errors for already deleted records. (#746, @euank)
- Add support for delegating DNS-01 challenges using CNAME records. (#670, @gurvindersingh)
- Fix a race that could cause ACME orders to fail despite them being in a 'valid' state (#764, @munnerz)
- Fix cleanup of Google Cloud DNS hosted zone for dns-01 challenge records (#754, @kragniz)
- Fix issue causing existing Ingresses to not be cleaned up properly after HTTP01 challenges in some cases (#831, @munnerz)
- Allow metadata server authentication for Google Cloud DNS (#664, @rpahli)
- Add RFC2136 DNS Provider (#661, @splashx)
@@ -0,0 +1,99 @@
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!
# Highlights
## Introducing ACME 'Order' and 'Challenge' CRDs
This release of cert-manager refactors how ACME certificates are handled significantly.
This should result in:
Fewer API calls to ACME servers - information about orders and challenges is now stored within the Kubernetes API
Better behaviour with regards to rate limits
A cleaner surface for debugging issues - we can now provide more context and information through the Events API as well as the 'status' field on our API types
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.
## Improved handling of ACME rate limits
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!
## Prometheus metrics for the ACME client
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.
## Validating resource webhook enabled by default
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.
## ECDSA keys supported for ACME certificates
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.
## Scalability improvements
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.
# Action Required
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.
# Changelog
## General
- Bump Go version to 1.11 (#1050, @munnerz)
- Removed the Git commit hash from the version string in non canary builds (#997) (#1021, @Nalum)
- Include ca.crt in created secrets for Issuers that support it (vault, ca and selfsigned) (#848, @Queuecumber)
- Added RBAC permissions for user facing roles to access Certificates and Issuers. (#902, @fuel-wlightning)
- Add global.priorityClassName option to Helm chart (#1190, @Art3mK)
- Add --namespace option to limit scope to a single namespace (#1188, @kragniz)
- Print more useful information about Certificate, Order and Challenge resources when running kubectl get (#1194, @munnerz)
## ACME Issuer
- 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 ACME HTTP client prometheus metrics (#1226, @munnerz)
- Reduce usage of ACME 'new-acct' endpoint (#1227, @munnerz)
- Disable TLS verification when self-checking (#1221, @DanielMorsing)
- Adds new flag --dns01-recursive-nameservers-only=[true|false] that defaults to false. When true, cert-manager will only ever query the configured DNS resolvers to perform the ACME DNS01 self check. This is useful in DNS constrained environments, where access to authoritative nameservers is restricted. Enabling this option could cause the DNS01 self check to take longer due to caching performed by the recursive nameservers. (#1184, @tlmiller)
- Retain Challenge resources when an Order has entered a failed state to make debugging easier (#1197, @munnerz)
- Increase back-off time between ACME order attempts on failure from 5m to 1h (#1195, @munnerz)
- Add 'reason' field when an order/challenge gets marked invalid (#1192, @DanielMorsing)
- Add DigitalOcean DNS Provider (#972, @aslafy-z)
## CA Issuer
- Update CA Issuer status condition usage (#961, @munnerz)
- It is now possible to include a certificate chain in the secret for the ca Issuer. This will then be propagated to generated certificates. (#1077, @mikebryant)
## Vault Issuer
- A new field caBundle added to the Vault Issuer configures a CA certificate used to validate the connection to the Vault Server. (#911, @vdesjardins)
## Bugfixes
- Increase time between retries for failing issuers and clusterissuers (#981, @munnerz)
- Fix concurrent map write race condition in ACME solver (#1033, @munnerz)
- Fix bug when updating ACME server URL on an existing Issuer resource (#1230, @munnerz)
- Fix issuing a certificate into a pre-existing secret resource (#1217, @munnerz)
- Fix affinity and tolerations declaration (#1209, @GuillaumeSmaha)
@@ -0,0 +1,81 @@
## Action Required
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.
## Highlights
### Venafi Issuer type
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.
### New cainjector controller
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.
### Improved webhook deployment
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.
### Experimental ARM support
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).
### Easier debugging of failing ACME challenges
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.
### Changelog since v0.6.0
- Add Venafi Cloud & TPP issuer type (#1250, @munnerz)
- cainjector: add support for injecting apiserver CA (#1420, @munnerz)
- Generate temporary self signed certificate whilst waiting for issuer to issue certificate (#1392, @munnerz)
- Added kubeprod as an alternative way to deploy cert-manager to the documentation (#1421, @arapulido)
- Use new cainjector controller for webhook APIService resource (#1415, @munnerz)
- Adds a controller for injecting CA data into webhooks and APIServices (#1398, @DirectXMan12)
- Bump Kubernetes dependencies to v1.13 (#1268, @munnerz)
- Use charts.jetstack.io instead of the helm/charts repository to publish Helm chart (#1377, @munnerz)
- Recreate dead solver pods during self-check (#1388, @DanielMorsing)
- Improve RFC2136 DNS01 provider documentation (#944, @briantopping)
- Add more information to Google CloudDNS guide (#1295, @wwwil)
- Add validation schema to CRD resources (#1322, @munnerz)
- Fire additional events when syncing ACME certificates fails (#1327, @munnerz)
- Publish arm32 and arm64 images for all cert-manager components (#1212, @munnerz)
- Extend ACME self check to check CAA records (#1325, @DanielMorsing)
- Bump Kubernetes apimachinery dependencies to v1.10.12 (#1344, @munnerz)
- Increase acmesolver default cpu resource limit to 100m (#1335, @munnerz)
- Fix potential race when updating secret resource (#1318, @munnerz)
- Fix bug causing certficates to be re-issued endlessly in certain edge cases (#1280, @munnerz)
- Fix bug when specify certificate keyAlgorithm without an explicit keySize (#1309, @munnerz)
- Bump Go version to 1.11.5 (#1304, @munnerz)
- Fix typo in SelfSigned Issuer in webhook deployment manifests (#1294, @munnerz)
- Add IP Address in CSR (#1128, @lrolaz)
- Allow to use PKCS#8 encoded private keys in CA issuers. (#1191, @chr-fritz)
- Add webhook troubleshooting guide (#1288, @munnerz)
- Overhaul documentation and add additional content (#1279, @munnerz)
- Increase x509 certificate duration from 90d to 1y for webhook component certificates (#1276, @munnerz)
- Fix bug where --dns01-recursive-nameservers flag was not respected when looking up the zone to update for a DNS01 challenge (#1266, @munnerz)
- Reuse acme clients to limit use of nonce/directory/accounts endpoints (#1265, @DanielMorsing)
- Surface self-check errors in challenge resource (#1244, @DanielMorsing)
@@ -0,0 +1,97 @@
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 grinning
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!
## Action required
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!
## New ACME configuration format
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.
## OpenShift installation instructions
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!
## Webhook based ACME DNS01 solver
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.
## Switch to structured logging
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!
## Changelog
- make email address an optional field in ACME issuers (#1483, @DanielMorsing)
- Fix bug when handling resources that have lastTransitionTime set to null (#1628, @munnerz)
- Allow Openshift to install cert-manager chart (#1395, @JGodin-C2C)
- Update documentation for new 'solvers' field (#1623, @munnerz)
- Fix issue where ingress-shim would not clear old configuration when migrating to the new 'solvers' field (#1620, @munnerz)
- Add new 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)
- Fixes additionalPrinterColumn formatting for Certificate resources (#1616, @munnerz)
- Fix update loop in certificates controller and add additional debug logging (#1602, @munnerz)
- Automatically retry expired Challenge resources (#1603, @munnerz)
-Build under MacOS. (#1601, @michaelfig)
- Disable the CAA check by default, and introduce a new --feature-gates=ValidateCAA=true option to enable it (#1585, @munnerz)
- Improve error handling when ACME challenges fail to Present or CleanUp (#1597, @munnerz)
- Add static label for solver identification to allow usage of custom service (#1575, @christianhuening)
- Fix issues running the cainjector controller on Kubernetes 1.9 (#1579, @munnerz)
- Fix upgrade bug where lastTransitionTime may be set to nil, rendering cert-manager inoperable without manual intervention (#1576, @munnerz)
- Add webhook based DNS01 provider (#1563, @munnerz)
- Add DNS01 provider conformance test suite (#1562, @munnerz)
- fix typo in the deployment template (#1546, @cpanato)
- Automatically generate LICENSES file (#1549, @munnerz)
- Switch to go modules for dependency management (#1523, @munnerz)
- Bump to use Go 1.12 (#1429, @munnerz)
- use authoritative nameservers for CAA checks (#1521, @DanielMorsing)
- Update certificate if issuer changes (#1512, @lentzi90)
- also whitelist ipv6 (#1497, @mdonoughe)
- Set default acmesolver image based on arch (#1494, @lentzi90)
- Improve logging in ACME HTTP01 solver (#1474, @munnerz)
- Run metrics server on cert-manager instances that have not been elected as leader (#1482, @kragniz)
- Switch to structured logging using logr (#1409, @munnerz)
- fixing the quickstart documentation to use the new helm chart repo charts.jetstack.io (#1468, @BradErz)
- Removes need for hostedZoneName to be specified. Uses discovered DNS zone name instead. (#1466, @logicfox)