diff --git a/.spelling b/.spelling index 433f8f210ca..313785d7f0f 100644 --- a/.spelling +++ b/.spelling @@ -479,13 +479,15 @@ v1.8.2 v1.9.0 v1.9.1 v1.10 +v1.11.0 +v1.12.0 v1alpha1 v1alpha2 v1alpha3 v1beta1 v2 v3 -vCert +VCert vendoring vendored versioning @@ -561,6 +563,38 @@ VCert v1.11.0 v1.11.1 v4.4.1 +secretless +TokenRequest +v1.12.0 +v1.12.0. +PodDisruptionBudgets +andrewsomething +avi-08 +e96wic +ExNG +g-gaston +jkroepke +malovme +maumontesilva +tobotg +TrilokGeer +waterfoul +yulng +vidarno +vinzent +dsonck92 +go.work +go.mod +validatingwebhookconfigurations +mutatingwebhookconfigurations +customresourcedefinitions +unlabelled +v1.27.1 +v0.6.0. +v4.4.1 +liveness +apiservices +arm64 # TEMPORARY # these are temporarily ignored because the spellchecker diff --git a/content/docs/configuration/acme/README.md b/content/docs/configuration/acme/README.md index 3c658510e03..51a9014ac16 100644 --- a/content/docs/configuration/acme/README.md +++ b/content/docs/configuration/acme/README.md @@ -65,7 +65,7 @@ spec: solvers: - http01: ingress: - class: nginx + ingressClassName: nginx ``` Solvers come in the form of [`dns01`](./dns01/README.md) and @@ -123,8 +123,9 @@ spec: solvers: - http01: ingress: - class: nginx + ingressClassName: nginx ``` + > Note: cert-manager versions pre-`v1.3.0` also required users to specify the > MAC algorithm for EAB by setting > `Issuer.spec.acme.externalAccountBinding.keyAlgorithm` field. This field is @@ -296,7 +297,7 @@ spec: solvers: - http01: ingress: - class: nginx + ingressClassName: nginx selector: matchLabels: "use-http01-solver": "true" diff --git a/content/docs/configuration/acme/http01/README.md b/content/docs/configuration/acme/http01/README.md index ee46fdbe405..e8663f6fdd7 100644 --- a/content/docs/configuration/acme/http01/README.md +++ b/content/docs/configuration/acme/http01/README.md @@ -43,7 +43,7 @@ spec: solvers: - http01: ingress: - class: nginx + ingressClassName: nginx ``` ## Options @@ -52,18 +52,32 @@ The HTTP01 Issuer supports a number of additional options. For full details on the range of options available, read the [reference documentation](../../../reference/api-docs.md#acme.cert-manager.io/v1.ACMEChallengeSolverHTTP01). -### `class` +### `ingressClassName` + +
-If the `class` field is specified, cert-manager will create new `Ingress` -resources in order to route traffic to the `acmesolver` pods, which are -responsible for responding to ACME challenge validation requests. +📌 The field `ingressClassName` was added in cert-manager 1.12. -If this field is not specified, and `name` is also not specified, -cert-manager will default to create *new* `Ingress` resources but will **not** -set the ingress class on these resources, meaning *all* ingress controllers -installed in your cluster will serve traffic for the challenge solver, -potentially incurring additional cost. +
+If the `ingressClassName` field is specified, cert-manager will create new +`Ingress` resources in order to route traffic to the `acmesolver` pods, which +are responsible for responding to ACME challenge validation requests. + +This is the recommended way of configuring the Ingress controller. Most Ingress +controllers support `ingressClassName`, with the notable exception of +ingress-gce (as per the page [Configure Ingress for external load +balancing](https://cloud.google.com/kubernetes-engine/docs/how-to/load-balance-ingress)). + +### `class` + +If the `class` field is specified, a new Ingress resource with a randomly +generated name will be created in order to solve the challenge. This new +resource will have an annotation with key `kubernetes.io/ingress.class` and +value set to the value of the `class` field. + +This field is only recommended with ingress-gce. ingress-gce [doesn't support the +`ingressClassName` field](https://cloud.google.com/kubernetes-engine/docs/how-to/load-balance-ingress). ### `name` @@ -77,6 +91,16 @@ This mode should be avoided when using ingress controllers that expose a single IP for all ingress resources, as it can create compatibility problems with certain ingress-controller specific annotations. +
+ +If `class` and `ingressClassName` are not specified, and `name` is also not +specified, cert-manager will default to create *new* `Ingress` resources but +will **not** set the ingress class on these resources, meaning *all* ingress +controllers installed in your cluster will serve traffic for the challenge +solver, potentially incurring additional cost. + +
+

`serviceType`

In rare cases it might be not possible/desired to use `NodePort` as type for the diff --git a/content/docs/configuration/vault.md b/content/docs/configuration/vault.md index c2dd25aee54..c5d6df09236 100644 --- a/content/docs/configuration/vault.md +++ b/content/docs/configuration/vault.md @@ -144,13 +144,125 @@ spec: key: token ``` + + ### Authenticating with Kubernetes Service Accounts -Vault can be configured so that applications can authenticate using Kubernetes -[`Service Account -Tokens`](https://kubernetes.io/docs/reference/access-authn-authz/service-accounts-admin). -You find documentation on how to configure Vault to authenticate using Service -Account Tokens [here](https://www.vaultproject.io/docs/auth/kubernetes.html). +The [Vault Kubernetes +Auth](https://developer.hashicorp.com/vault/docs/auth/kubernetes) allows +cert-manager to authenticate to Vault using a Kubernetes Service Account Token +in order to issue certificates using Vault as a certification authority. The +Kubernetes service account token can be provided in two ways: + +- [Secretless Authentication with a Service Account](#secretless-authentication-with-a-service-account) (recommended), +- [Authentication with a Static Service Account Token](#static-service-account-token). + +#### Secretless Authentication with a Service Account + +ℹī¸ This feature is available in cert-manager >= v1.12.0. + +With the secretless authentication with a service account, cert-manager creates +an ephemeral service account token using the TokenRequest API and uses it to +authenticate with Vault. These tokens are short-lived (10 minutes) and are +never stored to disk. + +This is the recommended authentication method because it does not rely on the +deprecated static service account tokens. The static service account tokens pose +a threat due to their infinite lifetime. Static service account tokens have been +disabled by default on Kubernetes 1.24. + +The first step is to create a `ServiceAccount` resource: + +```sh +kubectl create serviceaccount -n sandbox vault-issuer +``` + +Then add an RBAC Role so that cert-manager can get tokens for the +ServiceAccount: + +```yaml +apiVersion: rbac.authorization.k8s.io/v1 +kind: Role +metadata: + name: vault-issuer + namespace: sandbox +rules: + - apiGroups: [''] + resources: ['serviceaccounts/token'] + resourceNames: ['vault-issuer'] + verbs: ['create'] +--- +apiVersion: rbac.authorization.k8s.io/v1 +kind: RoleBinding +metadata: + name: vault-issuer + namespace: sandbox +subjects: + - kind: ServiceAccount + name: cert-manager + namespace: cert-manager +roleRef: + apiGroup: rbac.authorization.k8s.io + kind: Role + name: vault-issuer +``` + +Finally, create the Issuer resource: + +```yaml +apiVersion: cert-manager.io/v1 +kind: Issuer +metadata: + name: vault-issuer + namespace: sandbox +spec: + vault: + path: pki_int/sign/example-dot-com + server: https://vault.local + auth: + kubernetes: + role: my-app-1 + mountPath: /v1/auth/kubernetes + serviceAccountRef: + name: vault-issuer +``` + +> **Issuer vs. ClusterIssuer:** With an Issuer resource, you can only refer to a +> service account located in the same namespace as the Issuer. With a +> ClusterIssuer, the service account must be located in the namespace that is +> configured by the flag `--cluster-resource-namespace`. + +To create the role in Vault, you can use the following command: + +```bash +vault write auth/kubernetes/role/vault-issuer \ + bound_service_account_names=vault-issuer \ + bound_service_account_namespaces=sandbox \ + audience="vault://sandbox/vault-issuer" \ + policies=vault-issuer \ + ttl=1m +``` + +It is recommended to use a different Vault role each per Issuer or +ClusterIssuer. The `audience` allows you to restrict the Vault role to a single +Issuer or ClusterIssuer. The syntax is the following: + +```yaml +"vault:///" # For an Issuer. +"vault://" # For a ClusterIssuer. +``` + +The expiration duration for the Kubernetes tokens that are requested is +hard-coded to 10 minutes (that's the minimum accepted). The `ttl` field can be +as short as possible, since cert-manager requests a new token every time it +needs to talks to Vault. + +Although it is not recommended, you can also use the same Vault role for all of +your Issuers and ClusterIssuers by omitting the `audience` field and re-using +the same service account. + + +#### Authentication with a Static Service Account Token For the Vault issuer to use this authentication, cert-manager must get access to the token that is stored in a Kubernetes `Secret`. Kubernetes Service Account diff --git a/content/docs/installation/upgrading/ingress-class-compatibility.md b/content/docs/installation/upgrading/ingress-class-compatibility.md index 9cfe1830004..2f9d360d612 100644 --- a/content/docs/installation/upgrading/ingress-class-compatibility.md +++ b/content/docs/installation/upgrading/ingress-class-compatibility.md @@ -1,12 +1,21 @@ --- -title: Notes on Ingress Class Compatibility +title: Notes on the breaking change with the `class` field that happened in cert-manager v1.5.4 description: 'cert-manager installation: Notes on ingress classes and safe upgrades' --- -In cert-manager v1.5.4 we made a change to the HTTP-01 code which was not backwards compatible. -See [Regression: HTTP-01 challenges fail with Istio, Traefik, ingress-gce and Azure AGIC]. -[Regression: HTTP-01 challenges fail with Istio, Traefik, ingress-gce and Azure AGIC]: https://github.com/cert-manager/cert-manager/issues/4537 +> ⚠ī¸ This document focuses on the `class` field of the Issuer and ClusterIssuer +> resources and the annotation `kubernetes.io/ingress.class`. If you are +> interested in using `ingressClassName` on your Ingress resources when using +> cert-manager's HTTP-01 solver, see the page [Securing Ingress +> Resources](../../configuration/acme/http01#ingressclassname). + +In cert-manager v1.5.4 we made a change to the HTTP-01 code which was not +backwards compatible. Before v1.5.4, cert-manager was using the `class` field on +the Issuer and ClusterIssuer to add the annotation +`kubernetes.io/ingress.class`. In cert-manager v1.5.4, cert-manager stopped +setting the annotation. See [Regression: HTTP-01 challenges fail with Istio, +Traefik, ingress-gce and Azure AGIC]. In v1.5.5, v1.6.2 and 1.7.1 we fixed this problem. @@ -18,6 +27,8 @@ If you have cert-manager v1.5.3 (or below) you should skip v1.5.4 and instead: and you can ignore the rest of this document. +[Regression: HTTP-01 challenges fail with Istio, Traefik, ingress-gce and Azure AGIC]: https://github.com/cert-manager/cert-manager/issues/4537 + The following notes apply to anyone upgrading from cert-manager v1.5.4, v1.6.0, v1.6.1 on Kubernetes v1.19 or later. # Background @@ -49,9 +60,9 @@ compatibility is to only use the annotation, even when creating `v1` Ingresses. ## ingress-nginx -If you chose not to use the IngressClass `nginx` that is created by default by the Helm chart -(e.g., you named the IngressClass `nginx-outside`), you will need to add the flags -`--ingress-class` and `--ingress-class-by-name` to your ingress-nginx deployment: +If you chose not to use the IngressClass `nginx` that is created by default by +the Helm chart (e.g., you named the IngressClass `nginx-outside`), you will need +to add the flags `--ingress-class` to your ingress-nginx deployment: ``` --ingress-class=nginx-outside --ingress-class-by-name=true diff --git a/content/docs/installation/upgrading/upgrading-0.7-0.8.md b/content/docs/installation/upgrading/upgrading-0.7-0.8.md index e3fabdca71a..d77a253205e 100644 --- a/content/docs/installation/upgrading/upgrading-0.7-0.8.md +++ b/content/docs/installation/upgrading/upgrading-0.7-0.8.md @@ -78,7 +78,7 @@ spec: - selector: {} http01: ingress: - class: nginx + ingressClassName: nginx - selector: # Any Certificate resources, or Ingress resources that use # ingress-shim and match the below label selector will use this @@ -204,7 +204,7 @@ spec: - selector: {} http01: ingress: - class: nginx + ingressClassName: nginx - selector: # Any Certificate resources, or Ingress resources that use # ingress-shim and match the below label selector will use this diff --git a/content/docs/manifest.json b/content/docs/manifest.json index e8b2685a6ee..2c99b44c501 100644 --- a/content/docs/manifest.json +++ b/content/docs/manifest.json @@ -554,6 +554,10 @@ "title": "Introduction", "path": "/docs/release-notes/README.md" }, + { + "title": "v1.12", + "path": "/docs/release-notes/release-notes-1.12.md" + }, { "title": "v1.11", "path": "/docs/release-notes/release-notes-1.11.md" diff --git a/content/docs/reference/api-docs.md b/content/docs/reference/api-docs.md index 35d0f49d6ca..4943e086a69 100644 --- a/content/docs/reference/api-docs.md +++ b/content/docs/reference/api-docs.md @@ -785,6 +785,17 @@ description: >-

Optional service type for Kubernetes solver service. Supported values are NodePort or ClusterIP. If unset, defaults to NodePort.

+ + + ingressClassName +
+ string + + + (Optional) +

This field configures the field ingressClassName on the created Ingress resources used to solve ACME challenges that use this challenge solver. This is the recommended way of configuring the ingress class. Only one of class, name or ingressClassName may be specified.

+ + class @@ -793,7 +804,7 @@ description: >- (Optional) -

The ingress class to use when creating Ingress resources to solve ACME challenges that use this challenge solver. Only one of ‘class’ or ‘name’ may be specified.

+

This field configures the annotation kubernetes.io/ingress.class when creating Ingress resources to solve ACME challenges that use this challenge solver. Only one of class, name or ingressClassName may be specified.

@@ -975,6 +986,19 @@ description: >-

If specified, the pod’s service account

+ + + imagePullSecrets +
+ + []Kubernetes core/v1.LocalObjectReference + + + + (Optional) +

If specified, the pod’s imagePullSecrets

+ +

ACMEChallengeSolverHTTP01IngressPodTemplate

@@ -1011,7 +1035,7 @@ description: >- (Optional) -

PodSpec defines overrides for the HTTP01 challenge solver pod. Only the ‘priorityClassName’, ‘nodeSelector’, ‘affinity’, ‘serviceAccountName’ and ‘tolerations’ fields are supported currently. All other fields will be ignored.

+

PodSpec defines overrides for the HTTP01 challenge solver pod. Check ACMEChallengeSolverHTTP01IngressPodSpec to find out currently supported fields. All other fields will be ignored.



@@ -1074,6 +1098,19 @@ description: >-

If specified, the pod’s service account

+ + + +
+ imagePullSecrets +
+ + []Kubernetes core/v1.LocalObjectReference + +
+ (Optional) +

If specified, the pod’s imagePullSecrets

+
@@ -4796,6 +4833,31 @@ description: >- +

ServiceAccountRef

+

(Appears on: VaultKubernetesAuth)

+
+

ServiceAccountRef is a service account used by cert-manager to request a token. The audience cannot be configured. The audience is generated by cert-manager and takes the form vault://namespace-name/issuer-name for an Issuer and vault://issuer-name for a ClusterIssuer. The expiration of the token is also set by cert-manager to 10 minutes.

+
+ + + + + + + + + + + + + +
FieldDescription
+ name +
+ string +
+

Name of the ServiceAccount used to request a token.

+

VaultAppRole

(Appears on: VaultAuth)

@@ -4846,7 +4908,7 @@ description: >-

VaultAuth

(Appears on: VaultIssuer)

-

Configuration used to authenticate with a Vault server. Only one of tokenSecretRef, appRole or kubernetes may be specified.

+

VaultAuth is configuration used to authenticate with a Vault server. The order of precedence is [tokenSecretRef, appRole or kubernetes].

@@ -5012,9 +5074,23 @@ description: >- + + + +
+ (Optional)

The required Secret field containing a Kubernetes ServiceAccount JWT used for authenticating with Vault. Use of ‘ambient credentials’ is not supported.

+ serviceAccountRef +
+ + ServiceAccountRef + +
+ (Optional) +

A reference to a service account that will be used to request a bound token (also known as “projected token”). Compared to using “secretRef”, using this field means that you don’t rely on statically bound tokens. To use this field, you must configure an RBAC rule to let cert-manager request a token.

+
role @@ -5670,5 +5746,5 @@ description: >-

- Generated with gen-crd-api-reference-docs on git commit 7ebb5f515. + Generated with gen-crd-api-reference-docs on git commit ca9aaa0.

diff --git a/content/docs/release-notes/README.md b/content/docs/release-notes/README.md index 5af72409f9c..eccfdd07a13 100644 --- a/content/docs/release-notes/README.md +++ b/content/docs/release-notes/README.md @@ -3,6 +3,7 @@ title: Release Notes description: 'cert-manager release notes: Overview' --- +- [`v1.12`](./release-notes-1.12.md) - [`v1.11`](./release-notes-1.11.md) - [`v1.10`](./release-notes-1.10.md) - [`v1.9`](./release-notes-1.9.md) diff --git a/content/docs/release-notes/release-notes-0.9.md b/content/docs/release-notes/release-notes-0.9.md index d9a9be4aaae..564eb9c6e72 100644 --- a/content/docs/release-notes/release-notes-0.9.md +++ b/content/docs/release-notes/release-notes-0.9.md @@ -163,8 +163,8 @@ validate and so will be recreated. This should resume the order normally. ### Venafi Issuer -- Venafi: use vCert `v4.1.0` ([#1827](https://github.com/cert-manager/cert-manager/pull/1827), [`@munnerz`](https://github.com/munnerz)) -- Bump Venafi vCert dependency to latest version ([#1754](https://github.com/cert-manager/cert-manager/pull/1754), [`@munnerz`](https://github.com/munnerz)) +- Venafi: use VCert `v4.1.0` ([#1827](https://github.com/cert-manager/cert-manager/pull/1827), [`@munnerz`](https://github.com/munnerz)) +- Bump Venafi VCert dependency to latest version ([#1754](https://github.com/cert-manager/cert-manager/pull/1754), [`@munnerz`](https://github.com/munnerz)) ### Webhook diff --git a/content/docs/release-notes/release-notes-1.12.md b/content/docs/release-notes/release-notes-1.12.md new file mode 100644 index 00000000000..9a048ec28e8 --- /dev/null +++ b/content/docs/release-notes/release-notes-1.12.md @@ -0,0 +1,270 @@ +--- +title: Release 1.12 +description: 'cert-manager release notes: cert-manager 1.12' +--- + +cert-manager 1.12 brings support for JSON logging, a lower memory footprint, the +support for ephemeral service account tokens with Vault, and the support of the +`ingressClassName` field. We also improved on our ability to patch +vulnerabilities. + +## Major Themes + +### Support for JSON logging + +JSON logs are now available in cert-manager! A massive thank you to +[@malovme](https://github.com/malovme) for going the extra mile to get +[#5828](https://github.com/cert-manager/cert-manager/pull/5828) merged! + +To enable JSON logs, add the flag `--logging-format=json` to the three +deployments (`cert-manager`, `cert-manager-webhook`, and +`cert-manager-cainjector`). + +For example, if you are using the Helm chart: + +```bash +helm repo add --force-update jetstack https://charts.jetstack.io +helm upgrade --install cert-manager jetstack/cert-manager --namespace cert-manager \ + --set extraArgs='{--logging-format=json}' \ + --set webhook.extraArgs='{--logging-format=json}' \ + --set cainjector.extraArgs='{--logging-format=json}' +``` + +### Lower memory footprint + +In 1.12 we continued the work started in 1.11 to reduce cert-manager component's +memory consumption. + +#### Controller + +Caching of the full contents of all cluster `Secret`s can now be disabled by +setting a `SecretsFilteredCaching` alpha feature gate to true. This will ensure +that only `Secret` resources that are labelled with +`controller.cert-manager.io/fao` label are cached in full. Cert-manager +automatically adds this label to all `Certificate` `Secret`s. + +This change has been placed behind alpha feature gate as it could potentially +slow down large scale issuance because issuer credentials `Secret`s will now be +retrieved from kube-apiserver instead of local cache. To prevent the slow down, +users can manually label issuer `Secret`s with a +`controller.cert-manager.io/fao` label. +See the +[design](https://github.com/cert-manager/cert-manager/blob/master/design/20221205-memory-management.md) +and [implementation](https://github.com/cert-manager/cert-manager/pull/5824) for +additional details. +We would like to gather some feedback on this change before +it can graduate- please leave your comments on +(`cert-manager#6074`)[https://github.com/cert-manager/cert-manager/issues/6074]. + +Additionally, controller no longer watches and caches all `Pod` and `Service` +resources. +See [`cert-manager#5976`](https://github.com/cert-manager/cert-manager/pull/5976) for implementation. + +#### Cainjector + +[Cainjector's](../concepts/ca-injector.md) control loops have been refactored, so by default it should +consume up to half as much memory as before, see +[`cert-manager#5746`](https://github.com/cert-manager/cert-manager/pull/5746). + +Additionally, a number of flags have been added to cainjector that can be used +to scope down what resources it watches and caches. + +If cainjector is only used as part of cert-manager installation, it only needs +to inject CA certs to cert-manager's `MutatingWebhookConfiguration` and +`ValidatingWebhookConfiguration` from a `Secret` in cert-manager's installation +namespace so all the other injectable/source types can be turned off and +cainjector can be scoped to a single namespace, see the relevant flags below: + +```go +// cainjector flags +--namespace= \ +--enable-customresourcedefinitions-injectable=false \ +--enable-certificates-data-source=false \ +--enable-apiservices-injectable=false +``` + +See [`cert-manager#5766`](https://github.com/cert-manager/cert-manager/pull/5766) for more detail. + +A big thanks to everyone who put in time reporting and writing up issues +describing performance problems in large scale installations. + +### Faster Response to CVEs By Reducing Transitive Dependencies + +In cert-manager 1.12, we have worked on reducing the impacts that unsupported +dependencies have on our ability to patch CVEs. + +Each binary now has its own `go.mod` file. When a CVE is declared in an +unsupported minor version of a dependency, and that the only solution is to bump +the minor version of the dependency, we can now choose to make an exception and +bump that minor version but limit the impact to a single binary. + +For example, in cert-manager 1.10, we chose not to fix a CVE reported in Helm +because it was forcing us to bump the minor versions of `k8s.io/api` and many +other dependencies. + +A side effect of the new `go.mod` layout is that it's now easier to import +cert-manager in Go, in terms of transitive dependencies that might show up in +your `go.mod` files or potential version conflicts between cert-manager and your +other dependencies. + +The caveat here is that we still only recommend importing cert-manager in [very +specific circumstances](../contributing/importing.md), and the module changes +mean that if you imported some paths (specifically under `cmd` or some paths +under `test`) you might see broken imports when you try to upgrade. + +If you experience a break as part of this, we're sorry and we'd be interested to +chat about it. The vast majority of projects using cert-manager should notice no +impact, and there should be no runtime impact either. + +You can read more about this change in the design document +[`20230302.gomod.md`](https://github.com/cert-manager/cert-manager/blob/master/design/20230302.gomod.md). + +### Support for ephemeral service account tokens in Vault + +cert-manager can now authenticate to Vault using ephemeral service account +tokens (JWT). cert-manager already knew to authenticate to Vault using the +[Vault Kubernetes Auth +Method](https://developer.hashicorp.com/vault/docs/auth/kubernetes) but relied +on insecure service account tokens stored in Secrets. You can now configure +cert-manager in a secretless manner. With this new feature, cert-manager will +create an ephemeral service account token on your behalf and use that to +authenticate to Vault. + +> 📖 Read about [Secretless Authentication with a Service Account](../configuration/vault.md#secretless-authentication-with-a-service-account). + +This change was implemented in the pull request +[`cert-manager#5502`](https://github.com/cert-manager/cert-manager/pull/5502). + +### Support for `ingressClassName` in the HTTP-01 solver + +cert-manager now supports the `ingressClassName` field in the HTTP-01 solver. We +recommend using `ingressClassName` instead of the field `class` in your Issuers +and ClusterIssuers. + +> 📖 Read more about `ingressClassName` in the documentation page [HTTP01](../configuration/acme/http01/#ingressclassname). + +## Community + +We extend our gratitude to all the open-source contributors who have made +commits in this release, including: + +- [@andrewsomething](https://github.com/andrewsomething) +- [@avi-08](https://github.com/avi-08) +- [@dsonck92](https://github.com/dsonck92) +- [@e96wic](https://github.com/e96wic) +- [@ExNG](https://github.com/ExNG) +- [@erikgb](https://github.com/erikgb) +- [@g-gaston](https://github.com/g-gaston) +- [@james-callahan](https://github.com/james-callahan) +- [@jkroepke](https://github.com/jkroepke) +- [@lucacome](https://github.com/lucacome) +- [@malovme](https://github.com/malovme) +- [@maumontesilva](https://github.com/maumontesilva) +- [@tobotg](https://github.com/tobotg) +- [@TrilokGeer](https://github.com/TrilokGeer) +- [@vidarno](https://github.com/vidarno) +- [@vinzent](https://github.com/vinzent) +- [@waterfoul](https://github.com/waterfoul) +- [@yanggangtony](https://github.com/yanggangtony) +- [@yulng](https://github.com/yulng) + +Thanks also to the following cert-manager maintainers for their contributions during this release: + +- [@inteon](https://github.com/inteon) +- [@wallrj](https://github.com/wallrj) +- [@maelvls](https://github.com/maelvls) +- [@SgtCoDFish](https://github.com/SgtCoDFish) +- [@irbekrm](https://github.com/irbekrm) +- [@jakexks](https://github.com/jakexks) +- [@JoshVanL](https://github.com/JoshVanL) +- [@munnerz](https://github.com/munnerz) + +Equally thanks to everyone who provided feedback, helped users and raised issues +on GitHub and Slack, joined our meetings and talked to us at KubeCon! + +Special thanks to [@erikgb](https://github.com/erikgb) for continuously great +input and feedback and to [@lucacome](https://github.com/lucacome) for always +ensuring that our Kubernetes dependencies are up to date! + +Thanks also to the CNCF, which provides resources and support, and to the AWS +open source team for being good community members and for their maintenance of +the Private CA Issuer. + +In addition, massive thanks to Jetstack (by Venafi) for contributing developer +time and resources towards the continued maintenance of cert-manager projects. + +## Changes since v1.11.0 + +### Feature + +- Helm: Added PodDisruptionBudgets for cert-manager components to the Helm chart (disabled by default). ([#3931](https://github.com/cert-manager/cert-manager/pull/3931), [@e96wic](https://github.com/e96wic)) +- Added support for JSON logging (using `--logging-format=json`) ([#5828](https://github.com/cert-manager/cert-manager/pull/5828), [@malovme](https://github.com/malovme)) +- Added the --concurrent-workers flag that lets you control the number of concurrent workers for each of our controllers. ([#5936](https://github.com/cert-manager/cert-manager/pull/5936), [@inteon](https://github.com/inteon)) +- Adds `acme.solvers.http01.ingress.podTemplate.spec.imagePullSecrets` field to issuer spec to allow to specify image pull secrets for the ACME HTTP01 solver pod. ([#5801](https://github.com/cert-manager/cert-manager/pull/5801), [@malovme](https://github.com/malovme)) +- cainjector: + - New flags were added to the cainjector binary. They can be used to modify what injectable kinds are enabled. If cainjector is only used as a cert-manager's internal component it is sufficient to only enable validatingwebhookconfigurations and mutatingwebhookconfigurations injectable resources; disabling the rest can improve memory consumption. By default all are enabled. + - The `--watch-certs` flag was renamed to `--enable-certificates-data-source`. ([#5766](https://github.com/cert-manager/cert-manager/pull/5766), [@irbekrm](https://github.com/irbekrm)) +- Helm: you can now add volumes and volume mounts via Helm variables for the cainjector, webhook, and startupapicheck. ([#5668](https://github.com/cert-manager/cert-manager/pull/5668), [@waterfoul](https://github.com/waterfoul)) +- Helm: you can now enable the flags `--dns01-recursive-nameservers`, `--enable-certificate-owner-ref`, and `--dns01-recursive-nameservers-only` through Helm values. ([#5614](https://github.com/cert-manager/cert-manager/pull/5614), [@jkroepke](https://github.com/jkroepke)) +- **POTENTIALLY BREAKING**: the cert-manager binaries and some tests have been split into separate Go modules, allowing them to be easily patched independently. This should have no impact if you simply run cert-manager in your cluster. If you import cert-manager binaries, integration tests or end-to-end tests in Go, you may need to make code changes in response to this. See https://cert-manager.io/docs/contributing/importing/ for more details. ([#5880](https://github.com/cert-manager/cert-manager/pull/5880), [@SgtCoDFish](https://github.com/SgtCoDFish)) +- The DigitalOcean issuer now sets a cert-manager user agent string. ([#5869](https://github.com/cert-manager/cert-manager/pull/5869), [@andrewsomething](https://github.com/andrewsomething)) +- The HTTP-01 solver can now be configured to create Ingresses with an `ingressClassName`. The credit goes to @dsonck92 for implementing the initial PR. ([#5849](https://github.com/cert-manager/cert-manager/pull/5849), [@maelvls](https://github.com/maelvls)) +- The Vault issuer can now be used with ephemeral Kubernetes tokens. With the new `serviceAccountRef` field, cert-manager generates a short-lived token associated to the service account to authenticate to Vault. Along with this new feature, we have added validation logic in the webhook in order to check the `vault.auth` field when creating an Issuer or ClusterIssuer. Previously, it was possible to create an Issuer or ClusterIssuer with an invalid value for `vault.auth`. ([#5502](https://github.com/cert-manager/cert-manager/pull/5502), [@maelvls](https://github.com/maelvls)) +- The cert-manager controller container of the controller Pod now has a `/livez` endpoint and a default liveness probe, which fails if leader election has been lost and for some reason the process has not exited. The liveness probe is disabled by default. ([#5962](https://github.com/cert-manager/cert-manager/pull/5962), [@wallrj](https://github.com/wallrj)) +- Upgraded Gateway API to v0.6.0. ([#5768](https://github.com/cert-manager/cert-manager/pull/5768), [@yulng](https://github.com/yulng)) +- Webhook now logs requests to mutating/validating webhook (with `--v=5` flag) ([#5975](https://github.com/cert-manager/cert-manager/pull/5975), [@tobotg](https://github.com/tobotg)) +- Certificate issuances are always failed (and retried with a backoff) for denied or invalid CertificateRequests. + This is not necessarily a breaking change as due to a race condition this may already have been the case. ([#5887](https://github.com/cert-manager/cert-manager/pull/5887), [@irbekrm](https://github.com/irbekrm)) +- The cainjector controller can now use server-side apply to patch mutatingwebhookconfigurations, validatingwebhookconfigurations, apiservices, and customresourcedefinitions. This feature is currently in alpha and is not enabled by default. To enable server-side apply for the cainjector, add the flag --feature-gates=ServerSideApply=true to the deployment. ([#5991](https://github.com/cert-manager/cert-manager/pull/5991), [@inteon](https://github.com/inteon)) +- Helm: Egress 6443/TCP is now allowed in the webhook. This is required for OpenShift and OKD clusters for which the Kubernetes API server listens on port 6443 instead of 443. ([#5788](https://github.com/cert-manager/cert-manager/pull/5788), [@ExNG](https://github.com/ExNG)) + +### Documentation + +- Helm: the dead links in `values.yaml` are now working ([#5999](https://github.com/cert-manager/cert-manager/pull/5999), [@SgtCoDFish](https://github.com/SgtCoDFish)) + +### Bug or Regression + +- When using the `literalSubject` field on a Certificate resource, the IPs, URIs, DNS names, and email addresses segments are now properly compared. ([#5747](https://github.com/cert-manager/cert-manager/pull/5747), [@inteon](https://github.com/inteon)) +- When using the `jks` and `pkcs12` fields on a Certificate resource with a CA issuer that doesn't set the `ca.crt` in the Secret resource, cert-manager no longer loop trying to copy `ca.crt` into `truststore.jks` or `truststore.p12`. ([#5972](https://github.com/cert-manager/cert-manager/pull/5972), [@vinzent](https://github.com/vinzent)) +- Cmctl renew now prints an error message unless Certificate name(s) or --all are supplied ([#5896](https://github.com/cert-manager/cert-manager/pull/5896), [@maumontesilva](https://github.com/maumontesilva)) +- Fix development environment and go vendoring on Linux arm64. ([#5810](https://github.com/cert-manager/cert-manager/pull/5810), [@SgtCoDFish](https://github.com/SgtCoDFish)) +- Fix ordering of remote git tags when preparing integration tests ([#5910](https://github.com/cert-manager/cert-manager/pull/5910), [@SgtCoDFish](https://github.com/SgtCoDFish)) +- Helm: the flag `--acme-http01-solver-image` given to the variable `acmesolver.extraArgs` now has precedence over the variable `acmesolver.image`. ([#5693](https://github.com/cert-manager/cert-manager/pull/5693), [@SgtCoDFish](https://github.com/SgtCoDFish)) +- Ingress and Gateway resources will not be synced if deleted via [foreground cascading](https://kubernetes.io/docs/concepts/architecture/garbage-collection/#foreground-deletion). ([#5878](https://github.com/cert-manager/cert-manager/pull/5878), [@avi-08](https://github.com/avi-08)) +- The auto-retry mechanism added in VCert 4.23.0 and part of cert-manager 1.11.0 (#5674) has been found to be faulty. Until this issue is fixed upstream, we now use a patched version of VCert. This patch will slowdown the issuance of certificates by 9% in case of heavy load on TPP. We aim to release at an ulterior date a patch release of cert-manager to fix this slowdown. ([#5805](https://github.com/cert-manager/cert-manager/pull/5805), [@inteon](https://github.com/inteon)) +- Upgrade to go 1.19.6 along with newer helm and containerd versions and updated base images ([#5813](https://github.com/cert-manager/cert-manager/pull/5813), [@SgtCoDFish](https://github.com/SgtCoDFish)) +- cmctl: In order work around a hardcoded Kubernetes version in Helm, we now use a fake kube-apiserver version when generating the helm template when running `cmctl x install`. ([#5720](https://github.com/cert-manager/cert-manager/pull/5720), [@irbekrm](https://github.com/irbekrm)) + +### Other (Cleanup or Flake) + +- ACME account registration is now re-verified if account key is manually changed. ([#5949](https://github.com/cert-manager/cert-manager/pull/5949), [@TrilokGeer](https://github.com/TrilokGeer)) +- Add `make go-workspace` target for generating a go.work file for local development ([#5935](https://github.com/cert-manager/cert-manager/pull/5935), [@SgtCoDFish](https://github.com/SgtCoDFish)) +- Added a Makefile target to build a standalone E2E test binary: make e2e-build ([#5804](https://github.com/cert-manager/cert-manager/pull/5804), [@wallrj](https://github.com/wallrj)) +- Bump keystore-go to v4.4.1 to work around an upstream rewrite of history ([#5724](https://github.com/cert-manager/cert-manager/pull/5724), [@g-gaston](https://github.com/g-gaston)) +- Bump the distroless base images ([#5929](https://github.com/cert-manager/cert-manager/pull/5929), [@maelvls](https://github.com/maelvls)) +- Bumps base images ([#5793](https://github.com/cert-manager/cert-manager/pull/5793), [@irbekrm](https://github.com/irbekrm)) +- The memory usage of the controller has been reduced by only caching the metadata of Pods and Services. ([#5976](https://github.com/cert-manager/cert-manager/pull/5976), [@irbekrm](https://github.com/irbekrm)) +- Cainjector memory improvements: removes second cache of secrets, CRDs, validating/mutatingwebhookconfigurations and APIServices that should reduce memory consumption by about half. + **BREAKING:** users who are relying on cainjector to work when `certificates.cert-manager.io` CRD is not installed in the cluster, now need to pass `--watch-certificates=false` flag to cainjector else it will not start. + Users who only use cainjector as cert-manager's internal component and have a large number of `Certificate` resources in cluster can pass `--watch-certificates=false` to avoid cainjector from caching `Certificate` resources and save some memory. ([#5746](https://github.com/cert-manager/cert-manager/pull/5746), [@irbekrm](https://github.com/irbekrm)) +- Cainjector now only reconciles annotated objects of injectable kind. ([#5764](https://github.com/cert-manager/cert-manager/pull/5764), [@irbekrm](https://github.com/irbekrm)) +- Container images are have an OCI source label ([#5722](https://github.com/cert-manager/cert-manager/pull/5722), [@james-callahan](https://github.com/james-callahan)) +- The acmesolver pods created by cert-manager now have `automountServiceAccountToken` turned off. ([#5754](https://github.com/cert-manager/cert-manager/pull/5754), [@wallrj](https://github.com/wallrj)) +- The controller memory usage has been further decreased by ignoring annotations, labels and managed fields when caching Secret resources. ([#5966](https://github.com/cert-manager/cert-manager/pull/5966), [@irbekrm](https://github.com/irbekrm)) +- The controller binary now uses much less memory on Kubernetes clusters with large or numerous Secret resources. The controller now ignores the contents of Secrets that aren't relevant to cert-manager. This functionality is currently placed behind `SecretsFilteredCaching` feature flag. The filtering mechanism might, in some cases, slightly slow down issuance or cause additional requests to kube-apiserver because unlabelled Secret resources that cert-manager controller needs will now be retrieved from kube-apiserver instead of being cached locally. To prevent this from happening, users can label all issuer Secret resources with the `controller.cert-manager.io/fao: true` label. ([#5824](https://github.com/cert-manager/cert-manager/pull/5824), [@irbekrm](https://github.com/irbekrm)) +- The controller now makes fewer calls to the ACME server. + **POTENTIALLY BREAKING**: this PR slightly changes how the name of the Challenge resources are calculated. To avoid duplicate issuances due to the Challenge resource being recreated, ensure that there is no in-progress ACME certificate issuance when you upgrade to this version of cert-manager. ([#5901](https://github.com/cert-manager/cert-manager/pull/5901), [@irbekrm](https://github.com/irbekrm)) +- The number of calls made to the ACME server during the controller startup has been reduced by storing the private key hash in the Issuer's status. ([#6006](https://github.com/cert-manager/cert-manager/pull/6006), [@vidarno](https://github.com/vidarno)) +- We are now testing with Kubernetes v1.27.1 by default. ([#5979](https://github.com/cert-manager/cert-manager/pull/5979), [@irbekrm](https://github.com/irbekrm)) +- Updates Kubernetes libraries to `v0.26.2`. ([#5820](https://github.com/cert-manager/cert-manager/pull/5820), [@lucacome](https://github.com/lucacome)) +- Updates Kubernetes libraries to `v0.26.3`. ([#5907](https://github.com/cert-manager/cert-manager/pull/5907), [@lucacome](https://github.com/lucacome)) +- Updates Kubernetes libraries to `v0.27.1`. ([#5961](https://github.com/cert-manager/cert-manager/pull/5961), [@lucacome](https://github.com/lucacome)) +- Updates base images ([#5832](https://github.com/cert-manager/cert-manager/pull/5832), [@irbekrm](https://github.com/irbekrm)) +- Upgrade to Go 1.20 ([#5969](https://github.com/cert-manager/cert-manager/pull/5969), [@wallrj](https://github.com/wallrj)) +- Upgrade to go 1.19.5 ([#5712](https://github.com/cert-manager/cert-manager/pull/5712), [@yanggangtony](https://github.com/yanggangtony)) +- Validates that `certificate.spec.secretName` is a valid `Secret` name ([#5967](https://github.com/cert-manager/cert-manager/pull/5967), [@avi-08](https://github.com/avi-08)) +- `certificate.spec.secretName` Secrets will now be labelled with `controller.cert-manager.io/fao` label ([#5660](https://github.com/cert-manager/cert-manager/pull/5660), [@irbekrm](https://github.com/irbekrm)) + +### Uncategorized + +- We have replaced our python boilerplate checker with an installed Go version, removing the need to have Python installed when developing or building cert-manager. ([#6000](https://github.com/cert-manager/cert-manager/pull/6000), [@SgtCoDFish](https://github.com/SgtCoDFish)) diff --git a/content/docs/tutorials/acme/example/ingress-tls-final.yaml b/content/docs/tutorials/acme/example/ingress-tls-final.yaml index 5c90402c416..48f8094a852 100644 --- a/content/docs/tutorials/acme/example/ingress-tls-final.yaml +++ b/content/docs/tutorials/acme/example/ingress-tls-final.yaml @@ -3,10 +3,10 @@ kind: Ingress metadata: name: kuard annotations: - kubernetes.io/ingress.class: "nginx" cert-manager.io/issuer: "letsencrypt-prod" spec: + ingressClassName: nginx tls: - hosts: - example.example.com diff --git a/content/docs/tutorials/acme/example/ingress-tls.yaml b/content/docs/tutorials/acme/example/ingress-tls.yaml index f888087d675..60fef7448b6 100644 --- a/content/docs/tutorials/acme/example/ingress-tls.yaml +++ b/content/docs/tutorials/acme/example/ingress-tls.yaml @@ -3,10 +3,10 @@ kind: Ingress metadata: name: kuard annotations: - kubernetes.io/ingress.class: "nginx" cert-manager.io/issuer: "letsencrypt-staging" spec: + ingressClassName: nginx tls: - hosts: - example.example.com diff --git a/content/docs/tutorials/acme/example/ingress.yaml b/content/docs/tutorials/acme/example/ingress.yaml index a2b8f8c4bd5..0651471ca05 100644 --- a/content/docs/tutorials/acme/example/ingress.yaml +++ b/content/docs/tutorials/acme/example/ingress.yaml @@ -2,11 +2,10 @@ apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: kuard - annotations: - kubernetes.io/ingress.class: "nginx" + annotations: {} #cert-manager.io/issuer: "letsencrypt-staging" - spec: + ingressClassName: nginx tls: - hosts: - example.example.com diff --git a/content/docs/tutorials/acme/example/pomerium-production-issuer.yaml b/content/docs/tutorials/acme/example/pomerium-production-issuer.yaml index d802d4d07f9..f15a2899041 100644 --- a/content/docs/tutorials/acme/example/pomerium-production-issuer.yaml +++ b/content/docs/tutorials/acme/example/pomerium-production-issuer.yaml @@ -14,6 +14,6 @@ spec: name: letsencrypt-prod # Enable the HTTP-01 challenge provider solvers: - - http01: - ingress: - class: pomerium \ No newline at end of file + - http01: + ingress: + ingressClassName: pomerium diff --git a/content/docs/tutorials/acme/example/pomerium-staging-issuer.yaml b/content/docs/tutorials/acme/example/pomerium-staging-issuer.yaml index f7756ed4bbb..8f8b91992a7 100644 --- a/content/docs/tutorials/acme/example/pomerium-staging-issuer.yaml +++ b/content/docs/tutorials/acme/example/pomerium-staging-issuer.yaml @@ -16,4 +16,4 @@ spec: solvers: - http01: ingress: - class: pomerium \ No newline at end of file + ingressClassName: pomerium diff --git a/content/docs/tutorials/acme/example/production-issuer.yaml b/content/docs/tutorials/acme/example/production-issuer.yaml index f7676f2522c..16ed60e210b 100644 --- a/content/docs/tutorials/acme/example/production-issuer.yaml +++ b/content/docs/tutorials/acme/example/production-issuer.yaml @@ -13,6 +13,6 @@ spec: name: letsencrypt-prod # Enable the HTTP-01 challenge provider solvers: - - http01: - ingress: - class: nginx + - http01: + ingress: + ingressClassName: nginx diff --git a/content/docs/tutorials/acme/example/staging-issuer.yaml b/content/docs/tutorials/acme/example/staging-issuer.yaml index b733952029e..9b0f3372562 100644 --- a/content/docs/tutorials/acme/example/staging-issuer.yaml +++ b/content/docs/tutorials/acme/example/staging-issuer.yaml @@ -13,6 +13,6 @@ spec: name: letsencrypt-staging # Enable the HTTP-01 challenge provider solvers: - - http01: - ingress: - class: nginx + - http01: + ingress: + ingressClassName: nginx diff --git a/content/docs/tutorials/acme/http-validation.md b/content/docs/tutorials/acme/http-validation.md index d5cda8e658a..b61bf7c14bb 100644 --- a/content/docs/tutorials/acme/http-validation.md +++ b/content/docs/tutorials/acme/http-validation.md @@ -41,7 +41,7 @@ spec: - selector: {} http01: ingress: - class: nginx + ingressClassName: nginx ``` We have specified the ACME server URL for Let's Encrypt's [staging @@ -108,22 +108,29 @@ verify domain ownership. To verify ownership of each domain mentioned in an `http01` stanza, cert-manager will create a Pod, Service and Ingress that exposes an HTTP endpoint that satisfies the HTTP01 challenge. -The fields `ingress` and `ingressClass` in the `http01` stanza can be used to -control how cert-manager interacts with Ingress resources: - -- If the `ingress` field is specified, then an Ingress resource with the same - name in the same namespace as the Certificate must already exist and it will - be modified only to add the appropriate rules to solve the challenge. - This field is useful for the Google Cloud Loadbalancer ingress controller, - as well as a number of others, that assign a single public IP address for - each ingress resource. - Without manual intervention, creating a new ingress resource would cause any - challenges to fail. -- If the `ingressClass` field is specified, a new ingress resource with a - randomly generated name will be created in order to solve the challenge. - This new resource will have an annotation with key `kubernetes.io/ingress.class` - and value set to the value of the `ingressClass` field. - This works for the likes of the NGINX ingress controller. +The fields `ingressClassName`, `class`, and `name` in the `http01` stanza can be +used to control how cert-manager interacts with Ingress resources: + +- If the `ingressClassName` field is specified, a new ingress resource with a + randomly generated name will be created in order to solve the challenge. This + new resource will have the field `ingressClassName` with the value of the + `ingressClassName` field. This is the recommended way of configuring which + Ingress controller should be used. This works for the likes of the NGINX + ingress controller. +- If the `class` field is specified, a new ingress resource with a randomly + generated name will be created in order to solve the challenge. This new + resource will have an annotation with key `kubernetes.io/ingress.class` and + value set to the value of the `class` field. This field is only recommended + with ingress-gce which [does not support the `ingressClassName` + field](https://cloud.google.com/kubernetes-engine/docs/how-to/load-balance-ingress). +- If the `name` field is specified, then an Ingress resource with the same name + in the same namespace as the Certificate must already exist and it will be + modified only to add the appropriate rules to solve the challenge. This field + is useful for the Google Cloud Loadbalancer ingress controller, as well as a + number of others, that assign a single public IP address for each ingress + resource. Without manual intervention, creating a new ingress resource would + cause any challenges to fail. + - If neither are specified, new ingress resources will be created with a randomly generated name, but they will not have the ingress class annotation set. - If both are specified, then the `ingress` field will take precedence. diff --git a/content/docs/tutorials/acme/migrating-from-kube-lego.md b/content/docs/tutorials/acme/migrating-from-kube-lego.md index 89b3ffebc97..84992cb0fbd 100644 --- a/content/docs/tutorials/acme/migrating-from-kube-lego.md +++ b/content/docs/tutorials/acme/migrating-from-kube-lego.md @@ -156,7 +156,7 @@ spec: solvers: - http01: ingress: - class: nginx + ingressClassName: nginx ``` We then submit this file to our Kubernetes cluster: diff --git a/content/docs/tutorials/venafi/venafi.md b/content/docs/tutorials/venafi/venafi.md index 505276f626f..fd7f9dddead 100644 --- a/content/docs/tutorials/venafi/venafi.md +++ b/content/docs/tutorials/venafi/venafi.md @@ -553,9 +553,8 @@ kind: Ingress metadata: name: frontend-ingress namespace: demo - annotations: - kubernetes.io/ingress.class: "nginx" spec: + ingressClassName: nginx tls: - hosts: - example.com