vadimkim/cert-manager-webhook-hetzner

cert-manager webhook for Hetzner DNS API

cert-manager-webhook-hetzner's Issues

Release v0.1.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?

Feature Request: Keep old releases in Helm registry to not break existing release automations

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).

Current docker image not working (but the code does)

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

Tolerations or nodeSelector: error converting YAML to JSON

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

Add Helm test for testing cert-manager-webhook-hetzner is working well

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.

1. It should be default disabled, so that this does not fail on users first installation.
2. We would need some test hetzner credentials available on this repository, for adding it to the CI

Cert that I get looks weird

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?

Docker repository has old version

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)

unable to get secret `cert-manager`

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?

Secrets not found when running DNS01 provider conformance testing suite

nevermind

Collaborating

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

Unable to create challenge

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

Helm chart deployment via GitHub Actions

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.

invalid header field value for "Auth-Api-Token"

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.

Rebuild with newer cert-manager

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!

Deprecation warnings

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

Lots of "the server could not find the requested resource" errors

I have the same problem mentioned in the issue:

#40

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!

Invalid header field

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.

I can't get it working without `zoneName` in `ClusterIssuer`

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?

Permissions issue

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 ?

Improve getting started guide

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

Readme/Instructions - broken due to 404 for helm repo

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

docker image not working on Raspi4 aka arm64

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!

cannot deploy on kubernetes 1.22

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!

Lots of "the server could not find the requested resource" errors

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

FailedMount MountVolume.SetUp failed for volume "certs"

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

publish on a different registry

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.

Feature request: array of secretNames in values.yaml

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

Cannot get resource "secrets" in API group "" in the namespace "mynamespace"

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 secret hetzner-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"?

Missing RBAC for webhook?

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?

cert-manager default service account name changed

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?