vadimkim / cert-manager-webhook-hetzner Goto Github PK
View Code? Open in Web Editor NEWcert-manager webhook for Hetzner DNS API
Home Page: https://dns.hetzner.com/api-docs
License: Apache License 2.0
cert-manager webhook for Hetzner DNS API
Home Page: https://dns.hetzner.com/api-docs
License: Apache License 2.0
Since this repository is pretty well tested and experiences hardly any issues, I think it's safe to assume that we should introduce a semver release system. Should we kick off a release v0.1.0?
Since the latest release 1.1.1 the previous release 1.1.0 is not available anymore which breaks existing release automation workflows.
It would be great if you could keep old chart versions available. Maybe you could try to use the GitHub Helm-Chart-Releaser-Action and create a dedicated Git repo for the chart, if that would make it easier for you. If you need an example, I have a similar Helm Registry hosted that way, if you want to have a look at it (https://github.com/philmtd/helm-charts/blob/main/.github/workflows/release.yaml).
The current docker image zmejg/cert-manager-webhook-hetzner
does not work. I get an errors from the api that something is malformed but when I build a custom image from the current code everything works fine. So I think that the solution is just create a new image from the current code :)
For now I am using the following self build image as workaround: aronwolf/cert-manager-webhook-hetzner
Hi @vadimkim ,
thank you for this webook and Helm Chart. I hope it's still supported.
I found an issue if i set "tolerations" and/or nodeSelector keys in values yaml:
tolerations:
- key: "node-role.kubernetes.io/master"
operator: "Exists"
effect: NoSchedule
nodeSelector:
node-role.kubernetes.io/master: "true"
The returned error is:
YAML parse error on cert-manager-webhook-hetzner/templates/deployment.yaml: error converting YAML to JSON: yaml: line 58: did not find expected key
Are you able to check the template please? Dunno if @dgiebert can help too.
Thank you
Hi @vadimkim,
After fixing #60, we should add a simple Helm Chart test. See here.
This way we can assure that the webhook is always 100% working.
I used to try to use this tool on my home k3s.
I don't know the meaning of Group name (dint find it on Hetzner docs and not in the README), so I use my Zone name.
I do all steps in the README. I have seen the TXT Record was created in the Hetzner DNS Console, but after some seconds it was deleted.
Here is the log of the webhook-hetzner pod:
I am confused, the client IP is 10.42.0.251
this is an internal IP of the cluster. When I want to connect to my master, I use 192.168.178.42
. The remaining log looks pretty normal to me, no errors.
In the end, I have no Let's encrypt Cert on my Ingress. (Only the trafik default)
Am I doing something wrong with the Ingress controller or does the error occur earlier?
gh-pages branch contains released 1.1.0 template, but docker image at Docker hub is still version 1.0.0 (latest). I don't know what side effects it may cause, but I will create new docker image with new tag and upload it as (latest)
I installed cert-manager via helm, as well as this hetzner webhook.
I can generate self signed certificates but fail the dns-01 challenge.
The corresponding cert-manager pod logs this:
controller.go:167] "re-queuing item due to error processing" err="unable to get secret `cert-manager`; unable to find hetzner dns zone with: my-tld.com" logger="cert-manager.challenges"
my-tld.com is btw. only a placeholder for my domain.
I verified the API-Key and zone via Insomnia (like Postman) and was able to create a TXT Record via an API Request.
I don't even know where it's getting the secret "cert-manager" from. I used the default hetzner-secret from the ReadMe.
Anybody got an idea?
nevermind
Hello vadimkim,
Nice work you have done here ^^. Since we were impatient we also have done the same work.
https://github.com/mecodia/cert-manager-webhook-hetzner
But we are no Go Programmers (Python really), our code quality is not yet up to standard.
The question is now if you want to collaborate. We use the webhook in production and are really interested in something either we can maintain for longer or that gets maintained for the foreseeable future.
Let me know what your plan is and in what ways you would be open for collaboration. :-)
Beste regards,
Dennis
Hi, I have tried to create certificates for my domain. The authoritative DNS servers for the domain are at hetzner. I have created the following configs:
ClusterIssuer
---
apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
name: letsencrypt-production-hetzner
spec:
acme:
server: https://acme-v02.api.letsencrypt.org/directory
email: <email>
privateKeySecretRef:
name: letsencrypt-production-hetzner
solvers:
- selector:
dnsZones:
- "<zone.tld>"
dns01:
webhook:
groupName: <acme.zone.tld>
solverName: hetzner
config:
secretName: hetzner-secret
apiUrl: https://dns.hetzner.com/api/v1
Secret
---
apiVersion: v1
kind: Secret
metadata:
name: hetzner-secret
namespace: cert-manager
type: Opaque
data:
api-key: <secret>
I tried to specify the secret clear or as base64, the result is the same.
When I request a certificate with this config, a challenge is created in the cert-manager, but it fails with the following error message:
unable to get secret `cert-manager`; unable to find hetzner dns zone with: <zone.tld>.
Is there anything I might have overlooked? Thank you very much for your help
Hi @vadimkim,
Now that the new image is built via GH Actions, the next stept should be deploying the current helm chart to github-pages automatically via GH actions. If you agree I can submit a PR for this as well.
I am trying to setup the hetzner-webhook but it Keeps getting the Same Error and i dont Find any Solution.
Hopefully you can Help.
in the Logs of the Webhook Pod i can see that something with the API-Token Seems to be wrong..
main.go:159] unable to find id for zone name `mydomain.de`; unable to get zone info Get "https://dns.hetzner.com/api/v1/zones?name=mydomain.de": net/http: invalid header field value for "Auth-Api-Token"
I found this Issue: #23
Where the problem was caused by an newline character.
I checked for something similar, but without success. also i recognized that the Log-Message i get is slightly different.
i.e. in the Related Issue there were no qoutation marks around Auth-Api-Token and an dummy-value behind header field value.
I also checked that the zone exists in Hetzner and that my Api-key is right.
I even checked the Content of the actual Kubernetes-Secret.
Hopefully you can help me to solve this Problem
FullLog:
I0913 11:53:56.624305 1 requestheader_controller.go:169] Starting RequestHeaderAuthRequestController
I0913 11:53:56.624716 1 secure_serving.go:210] Serving securely on [::]:8443
I0913 11:53:56.624756 1 tlsconfig.go:240] "Starting DynamicServingCertificateController"
I0913 11:53:56.629620 1 apf_controller.go:361] Starting API Priority and Fairness config controller
I0913 11:53:56.624814 1 dynamic_serving_content.go:132] "Starting controller" name="serving-cert::/tls/tls.crt::/tls/tls.key"
I0913 11:53:56.624851 1 configmap_cafile_content.go:202] "Starting controller" name="client-ca::kube-system::extension-apiserver-authentication::client-ca-file"
I0913 11:53:56.630364 1 shared_informer.go:273] Waiting for caches to sync for client-ca::kube-system::extension-apiserver-authentication::client-ca-file
I0913 11:53:56.624872 1 configmap_cafile_content.go:202] "Starting controller" name="client-ca::kube-system::extension-apiserver-authentication::requestheader-client-ca-file"
I0913 11:53:56.630849 1 shared_informer.go:273] Waiting for caches to sync for client-ca::kube-system::extension-apiserver-authentication::requestheader-client-ca-file
I0913 11:53:56.625081 1 shared_informer.go:273] Waiting for caches to sync for RequestHeaderAuthRequestController
I0913 11:53:56.730498 1 apf_controller.go:366] Running API Priority and Fairness config worker
I0913 11:53:56.730752 1 apf_controller.go:369] Running API Priority and Fairness periodic rebalancing process
I0913 11:53:56.730560 1 shared_informer.go:280] Caches are synced for client-ca::kube-system::extension-apiserver-authentication::client-ca-file
I0913 11:53:56.731468 1 shared_informer.go:280] Caches are synced for RequestHeaderAuthRequestController
I0913 11:53:56.731618 1 shared_informer.go:280] Caches are synced for client-ca::kube-system::extension-apiserver-authentication::requestheader-client-ca-file
E0913 11:53:58.216619 1 main.go:159] unable to find id for zone name `mydomain.de`; unable to get zone info Get "https://dns.hetzner.com/api/v1/zones?name=mydomain.de": net/http: invalid header field value for "Auth-Api-Token"
E0913 11:53:58.216726 1 main.go:167] Post "https://dns.hetzner.com/api/v1/records": net/http: invalid header field value for "Auth-Api-Token"
I0913 11:53:58.216743 1 main.go:169] Added TXT record result:
I0913 11:53:58.216752 1 main.go:64] Presented txt record _acme-challenge.mydomain.de.
As mentioned in the issue you reported upstream, the webhook should be rebuilt against cert-manager >= 1.13 (cert-manager/webhook-example#27 (comment)), to solve problems related to OpenAPI AggregationController error.
Could you provide a newer build with dependencies mentioned above?
Thank you for your time & efforts on this very useful webhook!
I think it's safe to assume that these should be fixed for further k8s releases:
W1214 16:20:26.370463 22402 warnings.go:67] rbac.authorization.k8s.io/v1beta1 ClusterRole is deprecated in v1.17+, unavailable in v1.22+; use rbac.authorization.k8s.io/v1 ClusterRole
W1214 16:20:26.404466 22402 warnings.go:67] rbac.authorization.k8s.io/v1beta1 ClusterRoleBinding is deprecated in v1.17+, unavailable in v1.22+; use rbac.authorization.k8s.io/v1 ClusterRoleBinding
W1214 16:20:26.428766 22402 warnings.go:67] rbac.authorization.k8s.io/v1beta1 ClusterRoleBinding is deprecated in v1.17+, unavailable in v1.22+; use rbac.authorization.k8s.io/v1 ClusterRoleBinding
W1214 16:20:26.480120 22402 warnings.go:67] rbac.authorization.k8s.io/v1beta1 RoleBinding is deprecated in v1.17+, unavailable in v1.22+; use rbac.authorization.k8s.io/v1 RoleBinding
W1214 16:20:26.513577 22402 warnings.go:67] rbac.authorization.k8s.io/v1beta1 RoleBinding is deprecated in v1.17+, unavailable in v1.22+; use rbac.authorization.k8s.io/v1 RoleBinding
W1214 16:20:26.666324 22402 warnings.go:67] apiregistration.k8s.io/v1beta1 APIService is deprecated in v1.19+, unavailable in v1.22+; use apiregistration.k8s.io/v1 APIService
W1214 16:20:26.924584 22402 warnings.go:67] rbac.authorization.k8s.io/v1beta1 ClusterRole is deprecated in v1.17+, unavailable in v1.22+; use rbac.authorization.k8s.io/v1 ClusterRole
W1214 16:20:26.949916 22402 warnings.go:67] rbac.authorization.k8s.io/v1beta1 ClusterRole is deprecated in v1.17+, unavailable in v1.22+; use rbac.authorization.k8s.io/v1 ClusterRole
W1214 16:20:26.981854 22402 warnings.go:67] rbac.authorization.k8s.io/v1beta1 ClusterRole is deprecated in v1.17+, unavailable in v1.22+; use rbac.authorization.k8s.io/v1 ClusterRole
W1214 16:20:27.027524 22402 warnings.go:67] rbac.authorization.k8s.io/v1beta1 ClusterRoleBinding is deprecated in v1.17+, unavailable in v1.22+; use rbac.authorization.k8s.io/v1 ClusterRoleBinding
W1214 16:20:27.056995 22402 warnings.go:67] rbac.authorization.k8s.io/v1beta1 ClusterRoleBinding is deprecated in v1.17+, unavailable in v1.22+; use rbac.authorization.k8s.io/v1 ClusterRoleBinding
W1214 16:20:27.117368 22402 warnings.go:67] rbac.authorization.k8s.io/v1beta1 ClusterRoleBinding is deprecated in v1.17+, unavailable in v1.22+; use rbac.authorization.k8s.io/v1 ClusterRoleBinding
W1214 16:20:27.147111 22402 warnings.go:67] rbac.authorization.k8s.io/v1beta1 ClusterRoleBinding is deprecated in v1.17+, unavailable in v1.22+; use rbac.authorization.k8s.io/v1 ClusterRoleBinding
W1214 16:20:27.182060 22402 warnings.go:67] rbac.authorization.k8s.io/v1beta1 ClusterRoleBinding is deprecated in v1.17+, unavailable in v1.22+; use rbac.authorization.k8s.io/v1 ClusterRoleBinding
W1214 16:20:27.217475 22402 warnings.go:67] rbac.authorization.k8s.io/v1beta1 ClusterRoleBinding is deprecated in v1.17+, unavailable in v1.22+; use rbac.authorization.k8s.io/v1 ClusterRoleBinding
W1214 16:20:27.331302 22402 warnings.go:67] rbac.authorization.k8s.io/v1beta1 RoleBinding is deprecated in v1.17+, unavailable in v1.22+; use rbac.authorization.k8s.io/v1 RoleBinding
W1214 16:20:27.365783 22402 warnings.go:67] rbac.authorization.k8s.io/v1beta1 RoleBinding is deprecated in v1.17+, unavailable in v1.22+; use rbac.authorization.k8s.io/v1 RoleBinding
W1214 16:20:27.415702 22402 warnings.go:67] rbac.authorization.k8s.io/v1beta1 RoleBinding is deprecated in v1.17+, unavailable in v1.22+; use rbac.authorization.k8s.io/v1 RoleBinding
W1214 16:20:27.499574 22402 warnings.go:67] rbac.authorization.k8s.io/v1beta1 RoleBinding is deprecated in v1.17+, unavailable in v1.22+; use rbac.authorization.k8s.io/v1 RoleBinding
W1214 16:20:27.563580 22402 warnings.go:67] rbac.authorization.k8s.io/v1beta1 RoleBinding is deprecated in v1.17+, unavailable in v1.22+; use rbac.authorization.k8s.io/v1 RoleBinding
W1214 16:20:27.837687 22402 warnings.go:67] apiregistration.k8s.io/v1beta1 APIService is deprecated in v1.19+, unavailable in v1.22+; use apiregistration.k8s.io/v1 APIService
W1214 16:20:27.883667 22402 warnings.go:67] apiregistration.k8s.io/v1beta1 APIService is deprecated in v1.19+, unavailable in v1.22+; use apiregistration.k8s.io/v1 APIService
W1214 16:20:27.936623 22402 warnings.go:67] apiregistration.k8s.io/v1beta1 APIService is deprecated in v1.19+, unavailable in v1.22+; use apiregistration.k8s.io/v1 APIService
I have the same problem mentioned in the issue:
In my case, it is not possible to migrate to kubernetes version 1.26 yet.
Is there any previous version compatible with this version?
Thank you!
I0428 08:35:40.512767 1 main.go:166] Added TXT record result:
I0428 08:35:40.512772 1 main.go:60] Presented txt record _acme-challenge.test.k3s.xxxx.xx.
E0428 08:38:31.478141 1 main.go:156] unable to find id for zone name xxxx.xx
; unable to get zone info Get "https://dns.hetzner.com/api/v1/zones?name=xxxx.xx": net/http: invalid header field value "MYSECUREKEY\n" for key Auth-Api-Token
E0428 08:38:31.478173 1 main.go:164] Post "https://dns.hetzner.com/api/v1/records": net/http: invalid header field value "MYSECUREKEY\n" for key Auth-Api-Token
I0428 08:38:31.478181 1 main.go:166] Added TXT record result:
I0428 08:38:31.478185 1 main.go:60] Presented txt record _acme-challenge.test.k3s.xxxx.xx.
Hi, first of all thanks for your work.
I'm trying to use the Hetzner solver but it doesn't quite work.
I want to add a single ClusterIssuer
for multiple DNS zones, so I didn't add the zoneName
config to the issuer.
Then I created a simple certificate:
apiVersion: cert-manager.io/v1alpha2 # I tried with `v1` too, but no change
kind: Certificate
metadata:
name: test-cert
namespace: cert-manager
spec:
commonName: mydomain.com # I tried with or without commonName, same effect - the commonName is deprecated according to the cert-manager docs
dnsNames:
- mydomain.com
issuerRef:
name: letsencrypt-staging-dns
kind: ClusterIssuer
secretName: test-cert
I get this logs from the webhook pod:
splitting domain name _acme-challenge.mydomain.com. failed!
unable to find id for zone name ``; wrong number of zones in response 3 must be exactly = 1
Error calling API status:422 Unprocessable Entity url: https://dns.hetzner.com/api/v1/records method: POST
Error calling API status:422 Unprocessable Entity url: https://dns.hetzner.com/api/v1/records method: POST
Added TXT record result:
Presented txt record _acme-challenge.mydomain.com.
After looking at the code it looks like the zoneName is required even tho the docs say it's optional. The dnsNames
entry is the FQDN and equal to the Hetzner zone-name in my case.
Am I maybe missing something?
Hi!
I have cert-manager installed via helm with default settings. When installing this chart, I get the following permissions error:
rook-ceph 23m Warning PresentError challenge/ceph-tls-55tl8-3331809567-906918078 Error presenting challenge: hetzner.acme.example.org is forbidden: User "system:serviceaccount:cert-manager:certbot-cert-manager" cannot create resource "hetzner" in API group "acme.example.org" at the cluster scope
In my cert-manager deploy i have the following helm values set:
(jetstack certbot v1.6.1, pasting the terraform options as they directly translate to chart values)
set {
name = "global.rbac.create"
value = "true"
}
set {
name = "serviceAccount.create"
value = "true"
}
set {
name = "prometheus.enabled"
value = "false"
}
set {
name = "webhook.enabled"
value = "true"
}
set {
name = "cainjector.enabled"
value = "true"
}
set {
name = "installCRDs"
value = "true"
}
Whats going on here ?
I've had some issues figuring out how to get started with the webhook. It mainly was due to confusion on my side as to what a group is, and how to implement it. I was able to debug it, looking into the cert-manager logs, and then updating the helm groupName value but it wasn't very aparrent.
Maybe one should mention more about the group configuration (helm values) and also provide a noticeable default value in the cli commands such as --set groupName=acme.yourdomain.tld
In the readme we have:
helm repo add cert-manager-webhook-hetzner https://vadimkim.github.io/cert-manager-webhook-hetzner
The url https://vadimkim.github.io/cert-manager-webhook-hetzner now returns a 404 so the instructions are broken
First off: Big thank you for this! It is working like a charm with three of my clusters.
The fourth kubernetes "cluster" is on a Raspberry Pi 4, where the image does not work. Apparently the image is built for amd64 only, while the Raspi is arm64.
I have no clue on how to build docker images with multiple architectures, so I cannot help. But it would be really nice if this would work on arm64, too.
Thanks in advance!
Hello,
I would like to thank you for the time creating this wonderful addon. I've been using it for the last year and a half.
Unfortunately, I was not able to deploy the latest version after I upgraded to k8s 1.22, and I suspect that the previous one is also not working correct.
I get the following error when trying to upgrade through helm:
Error: UPGRADE FAILED: current release manifest contains removed kubernetes api(s) for this kubernetes version and it is therefore unable to build the kubernetes objects for performing the diff. error from kubernetes: [unable to recognize "": no matches for kind "ClusterRole" in version "rbac.authorization.k8s.io/v1beta1", unable to recognize "": no matches for kind "ClusterRoleBinding" in version "rbac.authorization.k8s.io/v1beta1", unable to recognize "": no matches for kind "RoleBinding" in version "rbac.authorization.k8s.io/v1beta1", unable to recognize "": no matches for kind "APIService" in version "apiregistration.k8s.io/v1beta1", unable to recognize "": no matches for kind "Certificate" in version "cert-manager.io/v1alpha2", unable to recognize "": no matches for kind "Issuer" in version "cert-manager.io/v1alpha2"]
I am guessing the problem is with some deprecated APIs but I haven't dug any deeper. Will you be able to have a look.
Thanks!
I found that cert-manager did not issue a certificate using webhook-hetzner today. The certificate stays in status "False". This did work last week, with the same version of the webhook.
Not sure if it is related, but I noticed that the webhook-hetzner pod spits out lots of warnings:
W0324 05:54:37.343426 1 reflector.go:424] pkg/mod/k8s.io/[email protected]/tools/cache/reflector.go:169: failed to list *v1beta3.FlowSchema: the server could not find the requested resource
E0324 05:54:37.343518 1 reflector.go:140] pkg/mod/k8s.io/[email protected]/tools/cache/reflector.go:169: Failed to watch *v1beta3.FlowSchema: failed to list *v1beta3.FlowSchema: the server could not find the requested resource
W0324 05:54:39.185135 1 reflector.go:424] pkg/mod/k8s.io/[email protected]/tools/cache/reflector.go:169: failed to list *v1beta3.PriorityLevelConfiguration: the server could not find the requested resource
E0324 05:54:39.185242 1 reflector.go:140] pkg/mod/k8s.io/[email protected]/tools/cache/reflector.go:169: Failed to watch *v1beta3.PriorityLevelConfiguration: failed to list *v1beta3.PriorityLevelConfiguration: the server could not find the requested resource
W0324 05:55:16.260741 1 reflector.go:424] pkg/mod/k8s.io/[email protected]/tools/cache/reflector.go:169: failed to list *v1beta3.FlowSchema: the server could not find the requested resource
E0324 05:55:16.260840 1 reflector.go:140] pkg/mod/k8s.io/[email protected]/tools/cache/reflector.go:169: Failed to watch *v1beta3.FlowSchema: failed to list *v1beta3.FlowSchema: the server could not find the requested resource
W0324 05:55:31.768006 1 reflector.go:424] pkg/mod/k8s.io/[email protected]/tools/cache/reflector.go:169: failed to list *v1beta3.PriorityLevelConfiguration: the server could not find the requested resource
E0324 05:55:31.768095 1 reflector.go:140] pkg/mod/k8s.io/[email protected]/tools/cache/reflector.go:169: Failed to watch *v1beta3.PriorityLevelConfiguration: failed to list *v1beta3.PriorityLevelConfiguration: the server could not find the requested resource
Do I need to be worried when seeing this in the events log?
Warning FailedMount 2m14s (x4 over 2m18s) kubelet MountVolume.SetUp failed for volume "certs" : secret "cert-manager-webhook-hetzner-webhook-tls" not found
It would be great to publish the image on another registry without draconian rate limits. I personally like quay.io which has a nice fair use policy, but there is also the (less highly available) github package registry.
Firstly, thanks for the very helpful tool. I have started using it in production, literally 2 minutes ago ๐
This feature would allow users to have multiple issuers, each with its own account on Hertzner with individual DNS API keys.
Would you mind considering this for the next release? My hacky work around at the moment is to manually create a role and role binding like this...
kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
name: cert-manager-webhook-hetzner:secret-reader-alt
namespace: cert-manager
rules:
- verbs:
- get
- watch
apiGroups:
- ""
resources:
- secrets
resourceNames:
- hetzner-secret-alt
---
kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
name: cert-manager-webhook-hetzner:secret-reader-alt
namespace: cert-manager
subjects:
- kind: ServiceAccount
name: cert-manager-webhook-hetzner
namespace: cert-manager
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: Role
name: cert-manager-webhook-hetzner:secret-reader-alt
Hi there,
I followed the instructions but I can't get a certificate.
Installed "Using public helm chart" with the flag --set groupName=acme.mydomain.com
Created a Issuer
apiVersion: cert-manager.io/v1
kind: Issuer
metadata:
name: letsencrypt-staging
namespace: mynamespace
spec:
acme:
server: https://acme-staging-v02.api.letsencrypt.org/directory
email: [email protected]
privateKeySecretRef:
name: letsencrypt-staging
solvers:
- dns01:
webhook:
groupName: acme.mydomain.com
solverName: hetzner
config:
secretName: hetzner-secret
zoneName: mydomain.com
apiUrl: https://dns.hetzner.com/api/v1
Created a Secret
apiVersion: v1
kind: Secret
metadata:
name: hetzner-secret
namespace: mynamespace
type: Opaque
data:
api-key: <MY API KEY>
Then I try to create a Certificate
apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
name: xyz-mydomain-com
namespace: mynamespace
spec:
commonName: xyz.mydomain.com
dnsNames:
- xyz.mydomain.com
issuerRef:
name: letsencrypt-staging
kind: Issuer
secretName: xyz-mydomain-com
Then I get the following error message under Challenges*
unable to get secret
mynamespace
; unable to get secrethetzner-secret/mynamespace
; secrets "hetzner-secret" is forbidden: User "system:serviceaccount:cert-manager:cert-manager-webhook-hetzner" cannot get resource "secrets" in API group "" in the namespace "mynamespace"
Is the namespace the problem?
Do I have to use the namespace "cert-manager"?
I used this for about a year, and now I noticed that I cannot get new certificates.
0222 18:02:29.828161 1 controller.go:167] cert-manager/challenges "msg"="re-queuing item due to error processing" "error"="XXX.YYY is forbidden: User \"system:serviceaccount:cert-manager:cert-manager\" cannot create resource \"XXX\" in API group \"YYY\" at the cluster scope" "key"="AAA/BBB-zh49m-3528166467-3830210674"
Not sure if I missed some changes during upgrades, or if something in Kubernetes needs special treatment now.
From what I found this might (or not...) be related to missing RBAC permissions. This issue seems similar.
So does this one, but that had another root cause (that I checked, my groupName is the same everywhere).
Any ideas?
We installed the helm chart cert-manager:0.4.8 from the bitnami catalog. After installing cert-manager-webhook-hetzner
and creating the certificate issuer and certificate itself, we encountered the error:
cert-manager User "system:serviceaccount:cert-system:cert-manager-controller" cannot create resource "hetzner" in API group "acme.example.tld"
We were able to solve the problem by changing the certManager.serviceAccountName
from cert-manager
to cert-manager-controller
. It seems like the new cert-manager version changes the default service account name. Should this change be reflected in this chart?
Is this related to #12?
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.