vadimkim / cert-manager-webhook-hetzner Goto Github PK

View Code? Open in Web Editor NEW

94.0 94.0 39.0 280 KB

cert-manager webhook for Hetzner DNS API

Home Page: https://dns.hetzner.com/api-docs

License: Apache License 2.0

Dockerfile 4.42% Makefile 3.76% Go 77.34% Shell 1.58% Mustache 12.91%

cert-manager-webhook hetzner-api kubernetes-service

cert-manager-webhook-hetzner's People

Contributors

Stargazers

Watchers

cert-manager-webhook-hetzner's Issues

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

Error during Cert generating

trying to generate a new letsencrypt cert. But no cert will be generated.
The webhook-hetzner throws following error:

Error message

I0815 14:25:55.995343       1 conditions.go:203] Setting lastTransitionTime for Certificate "fabianborn-tls" condition "Ready" to 2024-08-15 14:25:55.995298628 +0000 UTC m=+96231.164385928
I0815 14:25:55.995591       1 trigger_controller.go:215] "Certificate must be re-issued" logger="cert-manager.controller" key="default/fabianborn-tls" reason="DoesNotExist" message="Issuing certificate as Secret does not exist"
I0815 14:25:55.995702       1 conditions.go:203] Setting lastTransitionTime for Certificate "fabianborn-tls" condition "Issuing" to 2024-08-15 14:25:55.995676734 +0000 UTC m=+96231.164763923
I0815 14:25:56.081158       1 controller.go:157] "re-queuing item due to optimistic locking on resource" logger="cert-manager.controller" key="default/fabianborn-tls" error="Operation cannot be fulfilled on certificates.cert-manager.io \"fabianborn-tls\": the object has been modified; please apply your changes to the latest version and try again"
I0815 14:25:56.081427       1 trigger_controller.go:215] "Certificate must be re-issued" logger="cert-manager.controller" key="default/fabianborn-tls" reason="DoesNotExist" message="Issuing certificate as Secret does not exist"
I0815 14:25:56.081526       1 conditions.go:203] Setting lastTransitionTime for Certificate "fabianborn-tls" condition "Issuing" to 2024-08-15 14:25:56.081498953 +0000 UTC m=+96231.250586160
I0815 14:25:57.084648       1 controller.go:157] "re-queuing item due to optimistic locking on resource" logger="cert-manager.controller" key="default/fabianborn-tls" error="Operation cannot be fulfilled on certificates.cert-manager.io \"fabianborn-tls\": the object has been modified; please apply your changes to the latest version and try again"
I0815 14:25:57.146603       1 conditions.go:263] Setting lastTransitionTime for CertificateRequest "fabianborn-tls-1" condition "Approved" to 2024-08-15 14:25:57.146566059 +0000 UTC m=+96232.315653192
I0815 14:25:57.213534       1 conditions.go:263] Setting lastTransitionTime for CertificateRequest "fabianborn-tls-1" condition "Ready" to 2024-08-15 14:25:57.213498268 +0000 UTC m=+96232.382585383
I0815 14:25:57.240545       1 conditions.go:263] Setting lastTransitionTime for CertificateRequest "fabianborn-tls-1" condition "Ready" to 2024-08-15 14:25:57.240511578 +0000 UTC m=+96232.409598674
I0815 14:25:57.255622       1 controller.go:157] "re-queuing item due to optimistic locking on resource" logger="cert-manager.controller" key="default/fabianborn-tls-1" error="Operation cannot be fulfilled on certificaterequests.cert-manager.io \"fabianborn-tls-1\": the object has been modified; please apply your changes to the latest version and try again"
I0815 14:25:59.641949       1 dns.go:90] "presenting DNS01 challenge for domain" logger="cert-manager.controller.Present" resource_name="fabianborn-tls-1-1623950059-3431871651" resource_namespace="default" resource_kind="Challenge" resource_version="v1" dnsName="testcert.fabianborn.net" type="DNS-01" resource_name="fabianborn-tls-1-1623950059-3431871651" resource_namespace="default" resource_kind="Challenge" resource_version="v1" domain="testcert.fabianborn.net"
E0815 14:25:59.701271       1 controller.go:162] "re-queuing item due to error processing" err="unable to get secret `cert-manager`; unable to get secret `/cert-manager`; resource name may not be empty" logger="cert-manager.controller" key="default/fabianborn-tls-1-1623950059-3431871651"
I0815 14:25:59.703411       1 dns.go:90] "presenting DNS01 challenge for domain" logger="cert-manager.controller.Present" resource_name="fabianborn-tls-1-1623950059-3431871651" resource_namespace="default" resource_kind="Challenge" resource_version="v1" dnsName="testcert.fabianborn.net" type="DNS-01" resource_name="fabianborn-tls-1-1623950059-3431871651" resource_namespace="default" resource_kind="Challenge" resource_version="v1" domain="testcert.fabianborn.net"
E0815 14:25:59.717512       1 controller.go:162] "re-queuing item due to error processing" err="unable to get secret `cert-manager`; unable to get secret `/cert-manager`; resource name may not be empty" logger="cert-manager.controller" key="default/fabianborn-tls-1-1623950059-3431871651"
I0815 14:26:04.702519       1 dns.go:90] "presenting DNS01 challenge for domain" logger="cert-manager.controller.Present" resource_name="fabianborn-tls-1-1623950059-3431871651" resource_namespace="default" resource_kind="Challenge" resource_version="v1" dnsName="testcert.fabianborn.net" type="DNS-01" resource_name="fabianborn-tls-1-1623950059-3431871651" resource_namespace="default" resource_kind="Challenge" resource_version="v1" domain="testcert.fabianborn.net"
E0815 14:26:04.717079       1 controller.go:162] "re-queuing item due to error processing" err="unable to get secret `cert-manager`; unable to get secret `/cert-manager`; resource name may not be empty" logger="cert-manager.controller" key="default/fabianborn-tls-1-1623950059-3431871651"
I0815 14:26:24.717712       1 dns.go:90] "presenting DNS01 challenge for domain" logger="cert-manager.controller.Present" resource_name="fabianborn-tls-1-1623950059-3431871651" resource_namespace="default" resource_kind="Challenge" resource_version="v1" dnsName="testcert.fabianborn.net" type="DNS-01" resource_name="fabianborn-tls-1-1623950059-3431871651" resource_namespace="default" resource_kind="Challenge" resource_version="v1" domain="testcert.fabianborn.net"
E0815 14:26:24.740538       1 controller.go:162] "re-queuing item due to error processing" err="unable to get secret `cert-manager`; unable to get secret `/cert-manager`; resource name may not be empty" logger="cert-manager.controller" key="default/fabianborn-tls-1-1623950059-3431871651"

Config files

( clusterissuer.yaml)

---
apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
  name: letsencrypt-prod
  namespace: cert-manager
spec:
  acme:
    email: [email protected]
    privateKeySecretRef:
      name: letsencrypt-prod
    server: https://acme-v02.api.letsencrypt.org/directory
    solvers:
    ### Use this for Hetzner DNS Challenge
    - dns01:
        webhook:
          groupName: acme.company
          solverName: hetzner
          config:
            APIKey: apikey
            apiUrl: https://dns.hetzner.com/api/v1

apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: fabianborn-tls
spec:
  secretName: fabianborn-tls
  issuerRef:
    name: letsencrypt-prod
    kind: ClusterIssuer
  commonName: testcert.fabianborn.net
  dnsNames:
  - testcert.fabianborn.net

Versions:

cert-manager: v1.15.2
webhook-hetzner: v1.3.1
k3s: v1.27.16+k3s1

Logs flooded with "Unable to authenticate the request"

I'm migrating from mecodia/cert-manager-webhook-hetzner to this project on a Microk8s cluster. After removing the old certificate manager and configuring the new one as described in the documentation, I spotted that the CertificateRequest for the wildcard certificate stuck in the pending state having the following message:

Waiting on certificate issuance from order cert-manager/[redacted]-wildcard-cert-62rtw-3600047928: "pending"

Digging deeper, I observed that cert-manager-webhook-hetzner is fooding the logs with "Unable to authenticate the request" errors producing ~10 of these per second:

$ kubectl logs --namespace cert-manager cert-manager-webhook-hetzner-85d8cf5df7-tmgzh

I0824 11:08:07.912858       1 configmap_cafile_content.go:202] "Starting controller" name="client-ca::kube-system::extension-apiserver-authentication::client-ca-file"
I0824 11:08:07.912875       1 shared_informer.go:273] Waiting for caches to sync for client-ca::kube-system::extension-apiserver-authe ntication::client-ca-file
I0824 11:08:07.913013       1 configmap_cafile_content.go:202] "Starting controller" name="client-ca::kube-system::extension-apiserver-authentication::requestheader-client-ca-file"
I0824 11:08:07.913037       1 shared_informer.go:273] Waiting for caches to sync for client-ca::kube-system::extension-apiserver-authentication::requestheader-client-ca-file
W0824 11:08:07.914160       1 warnings.go:70] flowcontrol.apiserver.k8s.io/v1beta3 PriorityLevelConfiguration is deprecated in v1.29+, unavailable in v1.32+; use flowcontrol.apiserver.k8s.io/v1 PriorityLevelConfiguration
W0824 11:08:07.916215       1 warnings.go:70] flowcontrol.apiserver.k8s.io/v1beta3 FlowSchema is deprecated in v1.29+, unavailable in v1.32+; use flowcontrol.apiserver.k8s.io/v1 FlowSchema
W0824 11:08:07.918734       1 warnings.go:70] flowcontrol.apiserver.k8s.io/v1beta3 PriorityLevelConfiguration is deprecated in v1.29+, unavailable in v1.32+; use flowcontrol.apiserver.k8s.io/v1 PriorityLevelConfiguration
W0824 11:08:07.918896       1 warnings.go:70] flowcontrol.apiserver.k8s.io/v1beta3 FlowSchema is deprecated in v1.29+, unavailable in v1.32+; use flowcontrol.apiserver.k8s.io/v1 FlowSchema
I0824 11:08:08.011998       1 apf_controller.go:366] Running API Priority and Fairness config worker
I0824 11:08:08.012264       1 apf_controller.go:369] Running API Priority and Fairness periodic rebalancing process
I0824 11:08:08.013014       1 shared_informer.go:280] Caches are synced for client-ca::kube-system::extension-apiserver-authentication::client-ca-file
I0824 11:08:08.013038       1 shared_informer.go:280] Caches are synced for RequestHeaderAuthRequestController
I0824 11:08:08.013781       1 shared_informer.go:280] Caches are synced for client-ca::kube-system::extension-apiserver-authentication::requestheader-client-ca-file
E0824 11:08:09.168514       1 authentication.go:63] "Unable to authenticate the request" err="[x509: certificate has expired or is not yet valid: current time 2024-08-24T11:08:09Z is after 2024-07-06T06:57:54Z, verifying certificate SN=xxx720, SKID=, AKID=xxx:CF failed: x509: certificate has expired or is not yet valid: current time 2024-08-24T11:08:09Z is after 2024-07-06T06:57:54Z]"
E0824 11:08:09.169254       1 authentication.go:63] "Unable to authenticate the request" err="[x509: certificate has expired or is not yet valid: current time 2024-08-24T11:08:09Z is after 2024-07-06T06:57:54Z, verifying certificate SN=xxx720, SKID=, AKID=xxx:CF failed: x509: certificate has expired or is not yet valid: current time 2024-08-24T11:08:09Z is after 2024-07-06T06:57:54Z]"
E0824 11:08:09.176080       1 authentication.go:63] "Unable to authenticate the request" err="[x509: certificate has expired or is not yet valid: current time 2024-08-24T11:08:09Z is after 2024-07-06T06:57:54Z, verifying certificate SN=xxx720, SKID=, AKID=xxx:CF failed: x509: certificate has expired or is not yet valid: current time 2024-08-24T11:08:09Z is after 2024-07-06T06:57:54Z]"
...

It feels like an old certificate stuck somewhere in K8s which is causing that. Unfortunately, I'm not able to find the place where the respective error message is created as there is no authentication.go in the project. Maybe it's rel

I already tried to reinstall the cert-manager, cert-manager-webhook-hetzner as well as removed all certificates I could find without any success.

Do you have any ideas why the error logs are happening? Is it related to the endless "pending" state of the certificate?

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!

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.

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?

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!

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.

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

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

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.

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!

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

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?

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?

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

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?

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!

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

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 ?

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?

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

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)

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.

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

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

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.

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

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?

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

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

Secrets not found when running DNS01 provider conformance testing suite

nevermind

vadimkim / cert-manager-webhook-hetzner Goto Github PK

cert-manager-webhook-hetzner's People

Contributors

Stargazers

Watchers

Forkers

cert-manager-webhook-hetzner's Issues

Error message

Config files

Versions:

Recommend Projects

Recommend Topics

Recommend Org

Jobs