mirror of
https://github.com/cert-manager/webhook-example.git
synced 2025-07-02 23:05:48 +02:00
init
This commit is contained in:
parent
4753e58c17
commit
79834dee3c
1 changed files with 7 additions and 48 deletions
55
README.md
55
README.md
|
@ -1,54 +1,13 @@
|
||||||
# ACME webhook example
|
# WORK IN PROGRESS
|
||||||
|
|
||||||
The ACME issuer type supports an optional 'webhook' solver, which can be used
|
## description
|
||||||
to implement custom DNS01 challenge solving logic.
|
|
||||||
|
|
||||||
This is useful if you need to use cert-manager with a DNS provider that is not
|
cert-manager webhook is a plugin for bluecat to create letsencrypt certificates.
|
||||||
officially supported in cert-manager core.
|
|
||||||
|
|
||||||
## Why not in core?
|
## usage
|
||||||
|
|
||||||
As the project & adoption has grown, there has been an influx of DNS provider
|
* deploy cert-manager, see [here](https://github.com/jetstack/cert-manager)
|
||||||
pull requests to our core codebase. As this number has grown, the test matrix
|
* deploy plugin with helm, see [here](https://github.com/containeroo/helm-charts/tree/master/charts/cert-manager-webhook-bluecat)
|
||||||
has become un-maintainable and so, it's not possible for us to certify that
|
|
||||||
providers work to a sufficient level.
|
|
||||||
|
|
||||||
By creating this 'interface' between cert-manager and DNS providers, we allow
|
|
||||||
users to quickly iterate and test out new integrations, and then packaging
|
|
||||||
those up themselves as 'extensions' to cert-manager.
|
|
||||||
|
|
||||||
We can also then provide a standardised 'testing framework', or set of
|
_forked from [https://github.com/cert-manager/webhook-example](https://github.com/cert-manager/webhook-example)_
|
||||||
conformance tests, which allow us to validate the a DNS provider works as
|
|
||||||
expected.
|
|
||||||
|
|
||||||
## Creating your own webhook
|
|
||||||
|
|
||||||
Webhook's themselves are deployed as Kubernetes API services, in order to allow
|
|
||||||
administrators to restrict access to webhooks with Kubernetes RBAC.
|
|
||||||
|
|
||||||
This is important, as otherwise it'd be possible for anyone with access to your
|
|
||||||
webhook to complete ACME challenge validations and obtain certificates.
|
|
||||||
|
|
||||||
To make the set up of these webhook's easier, we provide a template repository
|
|
||||||
that can be used to get started quickly.
|
|
||||||
|
|
||||||
### Creating your own repository
|
|
||||||
|
|
||||||
### Running the test suite
|
|
||||||
|
|
||||||
All DNS providers **must** run the DNS01 provider conformance testing suite,
|
|
||||||
else they will have undetermined behaviour when used with cert-manager.
|
|
||||||
|
|
||||||
**It is essential that you configure and run the test suite when creating a
|
|
||||||
DNS01 webhook.**
|
|
||||||
|
|
||||||
An example Go test file has been provided in [main_test.go](https://github.com/jetstack/cert-manager-webhook-example/blob/master/main_test.go).
|
|
||||||
|
|
||||||
You can run the test suite with:
|
|
||||||
|
|
||||||
```bash
|
|
||||||
$ TEST_ZONE_NAME=example.com. make test
|
|
||||||
```
|
|
||||||
|
|
||||||
The example file has a number of areas you must fill in and replace with your
|
|
||||||
own options in order for tests to pass.
|
|
||||||
|
|
Loading…
Reference in a new issue