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>
Note that using ed25519 on the public internet is not currently
recommended, since it's not widely supported. You'd likely not be able
to use an Ed25519 cert with an ACME issuer today.
Ed25519 certs might be useful for internal PKI, though - an ed25519 CA
issuer, say - or for testing ed25519 certs before they become more
widely available on the public internet. They're not currently
supported by Vault, Venafi or ACME (Letsencrypt) issuers.
Signed-off-by: Anner J. Bonilla <abonilla@hoyosintegrity.com>
Signed-off-by: Anner J. Bonilla <annerjb@gmail.com>
Signed-off-by: Ashley Davis <ashley.davis@jetstack.io>
When running kyverno using https://kyverno.io/policies/pod-security/restricted/, some checks failed. This enables more secure policy by default
Signed-off-by: Mike Bryant <mikebryant@bulb.co.uk>
Signed-off-by: Richard Wall <richard.wall@jetstack.io>
The controller-gen tool is quite rude and won't tell you when one of the
CRD manifests cannot be parsed when the option schemapatch is used. As
an example, the following:
sed -i 's/RFC8555/RFC8556/g' pkg/apis/certmanager/v1/types_issuer.go
controller-gen schemapatch:manifests=./deploy/crds output:dir=./deploy/crds paths=./pkg/apis/...
should trigger a change in the crd-clusterissuers.yaml:
@@ -3184,7 +3184,7 @@ spec:
type: object
properties:
acme:
- description: ACME [...] communicate with a RFC8555
+ description: ACME [...] communicate with a RFC8556
type: object
Unfortunately, controller-gen v0.2.9-0.20200414181213-645d44dca7c0
silently skips faulty CRD manifests. In our case, the CRD had become a
non-YAML file (we need to use some if statements):
{{- if .Values.webhook.url.host }}
url: https://{{ .Values.webhook.url.host }}/convert
{{- else }}
service:
name: {{ template "webhook.fullname" . }}
namespace: {{ .Release.Namespace | quote }}
path: /convert
{{- end }}
Two issues can be found (we can use a YAML parser like yq for that):
1. The pipe "|" used in ".Release.Namespace | quote" makes it an invalid
YAML file. We could rewrite that to
{{ quote .Release.Namespace }}
but I decided to go with actual quotes like with the rest of the
file.
2. The {{ if }}, {{ else }} and {{ end }} are also invalid YAML syntax,
and one easy workaround is to comment them.
So many workarounds... but it now works!
Signed-off-by: Maël Valais <mael@vls.dev>
