Code Monkey home page Code Monkey logo

cert-manager-webhook-scaleway's Introduction

cert-manager Webhook for Scaleway DNS

cert-manager Webhook for Scaleway DNS is a ACME webhook for cert-manager allowing users to use Scaleway DNS for DNS01 challenge.

Getting started

Prerequisites

Installing

Attention: starting from 0.1.0 the chart's name is now named scaleway-certmanager-webhook, if upgrading from an older version you might want to add --set nameOverride=scaleway-webhook

  • Add scaleway's helm chart repository:
helm repo add scaleway https://helm.scw.cloud/
helm repo update
  • Install the chart
helm install scaleway-certmanager-webhook scaleway/scaleway-certmanager-webhook
  • Alternatively, you can install the webhook with default credentials with:
helm install scaleway-certmanager-webhook scaleway/scaleway-certmanager-webhook --set secret.accessKey=<YOUR-ACCESS-KEY> --set secret.secretKey=<YOUR-SECRET_KEY>

The Scaleway Webhook is now installed! ๐ŸŽ‰

Refer to the chart's documentation for more configuration options.

Alternatively, you may use the provided bundle for a basic install in the cert-manager namespace: kubectl apply -f https://raw.githubusercontent.com/scaleway/cert-manager-webhook-scaleway/main/deploy/bundle.yaml

How to use it

Note: It uses the cert-manager webhook system. Everything after the issuer is configured is just cert-manager. You can find out more in their documentation.

Now that the webhook is installed, here is how to use it. Let's say you need a certificate for example.com (should be registered in Scaleway DNS).

First step is to create a secret containing the Scaleway Access and Secret keys. Create the scaleway-secret.yaml file with the following content: (Only needed if you don't have default credentials as seen above).

apiVersion: v1
stringData:
  SCW_ACCESS_KEY: <YOUR-SCALEWAY-ACCESS-KEY>
  SCW_SECRET_KEY: <YOUR-SCALEWAY-SECRET-KEY>
kind: Secret
metadata:
  name: scaleway-secret
type: Opaque

And run:

kubectl create -f scaleway-secret.yaml

Next step is to create a cert-manager Issuer. Create a issuer.yaml file with the following content:

apiVersion: cert-manager.io/v1
kind: Issuer
metadata:
  name: my-scaleway-issuer
spec:
  acme:
    email: [email protected]
    # this is the acme staging URL
    server: https://acme-staging-v02.api.letsencrypt.org/directory
    # for production use this URL instead
    # server: https://acme-v02.api.letsencrypt.org/directory
    privateKeySecretRef:
      name: my-scaleway-private-key-secret
    solvers:
    - dns01:
        webhook:
          groupName: acme.scaleway.com
          solverName: scaleway
          config:
            # Only needed if you don't have default credentials as seen above.
            accessKeySecretRef:
              key: SCW_ACCESS_KEY
              name: scaleway-secret
            secretKeySecretRef:
              key: SCW_SECRET_KEY
              name: scaleway-secret

And run:

kubectl create -f issuer.yaml

Finally, you can now create the Certificate object for example.com. Create a certificate.yaml file with the following content:

apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: example-com
spec:
  dnsNames:
  - example.com
  issuerRef:
    name: my-scaleway-issuer
  secretName: example-com-tls

And run:

kubectl create -f certificate.yaml

After some seconds, you should see the certificate as ready:

$ kubectl get certificate example-com
NAME          READY   SECRET            AGE
example-com   True    example-com-tls   1m12s

Your certificate is now available in the example-com-tls secret!

Integration testing

Before running the test, you need:

  • A valid domain on Scaleway DNS (here example.com)
  • The variables SCW_ACCESS_KEY and SCW_SECRET_KEY valid and in the environment

In order to run the integration tests, run:

TEST_ZONE_NAME=example.com make test

cert-manager-webhook-scaleway's People

Contributors

dependabot[bot] avatar mathyv avatar nox-404 avatar paulden avatar raskyld avatar remyleone avatar sgtcodfish avatar sh4d1 avatar tacy-octo avatar vincentfretin avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

cert-manager-webhook-scaleway's Issues

Failed to create Order: 400 urn:ietf:params:acme:error:malformed: No Key ID in JWS header

Describe the bug
Unable to obtain certificates due to JWS header error.

Observed error:

Events:
  Type     Reason        Age   From          Message
  ----     ------        ----  ----          -------
  Normal   OrderCreated  12m   cert-manager  Created Order resource istio-system/**REDACTED**-26kl8-2320222416
  Normal   OrderPending  12m   cert-manager  Waiting on certificate issuance from order istio-system/**REDACTED**-26kl8-2320222416: ""
  Warning  OrderFailed   12m   cert-manager  Failed to wait for order resource "**REDACTED**-26kl8-2320222416" to become ready: order is in "errored" state: Failed to create Order: 400 urn:ietf:params:acme:error:malformed: No Key ID in JWS header

I have cert-manager installed in the cert-manager namespace, Istio in istio-system and I need to use ClusterIssuer resources as our apps are in various namespaces (we don't use default namespace for deployments).

The cert manager webhook was installed according to latest readme and using default credentials provisioning at install time.

  • Scaleway Cert Manager Webhook version: latest (git clone install flow)
  • Platform: Amazon EKS
  • Kubernetes version: v1.18.9-eks

kubectl only procedure

Is your feature request related to a problem? Please describe.
Using helm is heaving and lacks of auditability and adaptability to security parameters - rbac...

Describe the solution you'd like
I'd like a kubectl deployment alternative for this cert-manager to allow.

Describe alternatives you've considered
Recoding webhook by myself, using other cert webooks:

Additional context
Add any other context or screenshots about the feature request here.

The `bundle.yaml` file does not contain all required namespaces

Describe the bug
Deployment with bundle.yaml will fail because the Certificate is in a different namespace (cert-manager) than the pod (default) so the generated secret is not accessible.

To Reproduce
Steps to reproduce the behavior:
Try to deploy bundle.yaml

Expected behavior
It should deploy

Details (please complete the following information):

  • Scaleway Cert Manager Webhook version: v0.1.0
  • Platform: ?
  • Kubernetes version: 1.29.1

Additional context
This patch fixes it by making sure everything is deployed in the cert-manager namespace:

--- bundle.yaml 2024-05-08 19:23:13.076578543 +0200
+++ scaleway-webhook.yaml       2024-05-08 19:15:09.796100765 +0200
@@ -3,6 +3,7 @@
 kind: ServiceAccount
 metadata:
   name: scaleway-certmanager-webhook
+  namespace: cert-manager
   labels:
     app: scaleway-certmanager-webhook
 ---
@@ -11,6 +12,7 @@
 kind: ClusterRole
 metadata:
   name: scaleway-certmanager-webhook:domain-solver
+  namespace: cert-manager
   labels:
     app: scaleway-certmanager-webhook
 rules:
@@ -27,6 +29,7 @@
 kind: ClusterRoleBinding
 metadata:
   name: scaleway-certmanager-webhook:auth-delegator
+  namespace: cert-manager
   labels:
     app: scaleway-certmanager-webhook
 roleRef:
@@ -43,6 +46,7 @@
 kind: ClusterRoleBinding
 metadata:
   name: scaleway-certmanager-webhook:domain-solver
+  namespace: cert-manager
   labels:
     app: scaleway-certmanager-webhook
 roleRef:
@@ -113,6 +117,7 @@
 kind: Service
 metadata:
   name: scaleway-certmanager-webhook
+  namespace: cert-manager
   labels:
     app: scaleway-certmanager-webhook
 spec:
@@ -129,6 +134,7 @@
 kind: Deployment
 metadata:
   name: scaleway-certmanager-webhook
+  namespace: cert-manager
   labels:
     app: scaleway-certmanager-webhook
 spec:
@@ -183,6 +189,7 @@
 kind: APIService
 metadata:
   name: v1alpha1.acme.scaleway.com
+  namespace: cert-manager
   labels:
     app: scaleway-certmanager-webhook
   annotations:

Helm install fails on latest version

Describe the bug
Running the install command with the current latest commit returns

Error: INSTALLATION FAILED: template: scaleway-webhook/templates/deployment.yaml:23:22: executing "scaleway-webhook/templates/deployment.yaml" at <.Values.server.imagePullSecrets>: nil pointer evaluating interface {}.imagePullSecrets

To Reproduce
Steps to reproduce the behavior:
helm install Scaleway-webhook deploy/scaleway-webhook

Expected behavior
The install command installs the web hook

Details (please complete the following information):

  • Scaleway Cert Manager Webhook version: commit 3445b89
  • Platform: macOS
  • Kubernetes version: v1.27.0

Additional context
I pulled a commit before the latest (d344bee143e3ae9ed173b27769c59efe6b3871c2) and this one managed to install fine.

Logs spammed with RBAC issue

Describe the bug
Looking at the logs for the pod I can see these error messages spammed:

[email protected]/tools/cache/reflector.go:167: Failed to watch *v1beta1.PriorityLevelConfiguration: failed to list *v1beta1.PriorityLevelConfiguration: prioritylevelconfigurations.flowcontrol.apiserver.k8s.io is forbidden: User "system:serviceaccount:cert-manager:scaleway-webhook" cannot list resource "prioritylevelconfigurations" in API group "flowcontrol.apiserver.k8s.io" at the cluster scope

To Reproduce
Just install it and look at the pod logs

Expected behavior
No errors

Details (please complete the following information):

  • Scaleway Cert Manager Webhook version: latest
  • Platform: ?
  • Kubernetes version: 1.29.1

Additional context
The solution is described in this other webhook provider here:

puzzle/cert-manager-webhook-dnsimple#8 (comment)

The reason why this pops up is also described in that same issue. I applied an extra cluster role as suggested in the comment and it worked.

I don't use the Helm chart, but I created my own set of YAML files based on the chart, so I can't provide the patch.

Variabilize durations in PKI certificates

Hello,

Thanks for your work on this webhook!

Is your feature request related to a problem? Please describe.
I am using this webhook to generate certificates on domain names managed on Scaleway. This is deployed using ArgoCD which auto-syncs applications, in this case the chart provided in deploy/scaleway-webhook and the durations provided in the PKI is non-standard, causing a constant diff (and thus a constant re-sync):

Capture du 2021-04-21 12-24-09

Describe the solution you'd like
I suggest we could variabilize the durations so that clients may use whatever format seems fine to them. Additional benefit is that clients may choose other durations instead of the default ones suggested.

Describe alternatives you've considered
I haven't thought of any but I'm open to suggestions.

Additional context
I am creating a PR associated with the issue, I'm open to suggestions since I do not know if you have standards. Thanks again for your work!

Paul

multilevel domain name can't be used for ACME challenge

Describe the bug

I have a zone in scaleway DNS with scw.mydomain.com

With external DNS, I can create a domain like test.subdomain.scw.mydomain.com this works fine on Scaleway and AWS and the records is used in Scaleway.

When using this webhook with cert-manager and acme DNS-01 Challenge it fails with failed to update DNS zone recrds: scaleway-sdk-go: http error 403 Forbidden: domain not found because this only parse the first . When using cert-manager with route53 there is no issue with subdomain not declare as a "real" zone.

A workaround would be to actually create the zone but it is not practical for me. Is there any way to check from the last . and try to match a zone and iterate like this. And picking the last one found ?

To Reproduce
Use a multi level domain name as a record

Expected behavior
ACME Challenge is created

Details (please complete the following information):

  • Scaleway Cert Manager Webhook version: 0.0.1
  • Platform: kapsule 1.22
  • Kubernetes version: Kapsule 1.22

Helm repository

Is your feature request related to a problem? Please describe.
I would like to be able to install the chart without having to clone the Git repository.

Describe the solution you'd like
It should be made available in a public Helm chart repository.
https://helm.sh/docs/topics/chart_repository/

Certficate requests for domains spanning multiple projects

Is your feature request related to a problem? Please describe.
API keys are per-project. Creating certificates for domains managed by different projects isn't straight-forward and impossible if trying to use only one issuer.

Describe the solution you'd like
Proper IAM support would be ideal, but that's probably a lot of work. (And not directly related to the webhook: I've created a feature request)

Describe alternatives you've considered
The ability to specify multiple API keys in the scaleway-secret, and having it find and use the correct one for the domain specified.
It's also possible to create multiple issuers, one for each project, but this adds an extra layer of complexity.

A caveat to both these alternatives is that there'll be SCW credentials to manage what might be a substantial part of your cloud infrastructure just lying around as Kubernetes secrets.

Additional context
This has caused a lot of headaches.
What we ended up doing was moving all managed DNS zones to the same project and creating an API key for that, but that's far from ideal and a very hacky and time-consuming solution.

Using deprecated flowcontrol api

Describe the bug
After applying the extra role as described in #21 I still get errors because now it can search for the resources but they are not actually present in the cluster.

[email protected]/tools/cache/reflector.go:167: Failed to watch *v1beta1.PriorityLevelConfiguration: failed to list *v1beta1.PriorityLevelConfiguration: the server could not find the requested resource
E0502 21:36:13.356046       1 reflector.go:138] pkg/mod/k8s.io/[email protected]/tools/cache/reflector.go:167: Failed to watch *v1beta1.FlowSchema: failed to list *v1beta1.FlowSchema: the server could not find the requested resource

To Reproduce
Install with the extra role as described in #21

Expected behavior
No errors

Details (please complete the following information):

  • Scaleway Cert Manager Webhook version: latest
  • Platform: ?
  • Kubernetes version: 1.29.1

Additional context
v1beta1 of flowcontrol has been removed since 1.26, v1 is released since 1.29 or alternatively v1beta3 can be used from 1.26 - 1.29

Since the error occurs in client-go perhaps an update of the go dependency is enough to fix this?

is the project dead ?

Hello,

I would like to use cert manager with this webhook as I don't see any commit and with a major issue for my use case #8, is this project is still maintained ? Just asking before writing something :)

Regards,

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.