Kubernetes is removing support for the v1beta1 Ingress type in 1.22: https://kubernetes.io/blog/2021/07/14/upcoming-changes-in-kubernetes-1-22/#api-changes
However, we still wish to support k8s v1.16 until mid 2022 when Openshift 3 becomes out of support.
cert-manager will now use v1 Ingress if available by using the discovery API.
Signed-off-by: Jake Sanders <i@am.so-aweso.me>
see also https://github.com/jetstack/cert-manager/issues/4142
EncodeX509Chain checked for self-signed certs by comparing the subject
and issuer of the cert in question, which is invalid since it's
perfectly fine for those to match.
the correct behavior is to use cert.CheckSignatureFrom(cert). this bug
was exposed in 1.4 when ParseSingleCertificateChain started using
EncodeX509Chain in the critical path of several issuers; when end-users
had leaf certificates with subjects matching their issuer's subject, the
bug was triggered.
includes newly written tests for EncodeX509Chain and a test for
ParseSingleCertificateChain
Signed-off-by: Ashley Davis <ashley.davis@jetstack.io>
This bug can be reproduced using "go run -race" and by creating many
Certificates and renewing them continuously. With 5000 Certificate
objects, a data race is found in less than a minute.
Signed-off-by: Maël Valais <mael@vls.dev>
Note that the gateway-shim is only half the work for supporting the
Gateway API in cert-manager. The other half is the HTTP01 solver
support, which is still worked on.
The Gateway API in cert-manager is releases as an experimental feature
and needs to be enabled manually with the following flag:
--controllers=*,gateway-shim
All the annotations supported by ingress-shim are also supported by
gateway-shim, with some exceptions:
"acme.cert-manager.io/http01-ingress-class"
This annotation is not supported on the Gateway resource. Although the
Gateway resource also has a "gatewayClass" field, we will need to add
another field instead of "ingress-class" to avoid confusion with the
ingress-shim.
"acme.cert-manager.io/http01-edit-in-place"
This annotation is not supported because it is specific to some ingress
controllers like ingress-gce.
"kubernetes.io/tls-acme"
This annotation is not supported because it is a behavior inherited from
kube-lego and we chose not to keep this behavior with the Gateway API.
Unlike the ingress-shim, you can reuse the same Secret name in multiple
TLS configurations on the same Gateway resource.
The ingress-shim now shows the exact location of the duplicate
secretName when the user gives the same secretName in two separate TLS
blocks.
Signed-off-by: Maël Valais <mael@vls.dev>
Co-authored-by: Jake Sanders <i@am.so-aweso.me>
The switch statement was making it a bit harder to read. I also renamed
variables to make more sense in the context of this function.
Signed-off-by: Maël Valais <mael@vls.dev>