https://github.com/stackitcloud/stackit-cert-manager-webhook
A webhook integration for Cert Manager that enables STACKIT DNS usage via its API as a DNS01 ACME Issuer. This repository provides Helm-based deployment, operational guidance for multiple Issuer configurations, and a comprehensive testing suite.
https://github.com/stackitcloud/stackit-cert-manager-webhook
cert-manager cert-manager-webhook clouddns dns dns-provider kubernetes stackit stackit-cloud webhook
Last synced: 3 months ago
JSON representation
A webhook integration for Cert Manager that enables STACKIT DNS usage via its API as a DNS01 ACME Issuer. This repository provides Helm-based deployment, operational guidance for multiple Issuer configurations, and a comprehensive testing suite.
- Host: GitHub
- URL: https://github.com/stackitcloud/stackit-cert-manager-webhook
- Owner: stackitcloud
- License: apache-2.0
- Created: 2023-08-22T06:39:21.000Z (almost 3 years ago)
- Default Branch: main
- Last Pushed: 2026-04-27T13:49:54.000Z (3 months ago)
- Last Synced: 2026-04-27T15:31:20.645Z (3 months ago)
- Topics: cert-manager, cert-manager-webhook, clouddns, dns, dns-provider, kubernetes, stackit, stackit-cloud, webhook
- Language: Go
- Homepage: https://www.stackit.de
- Size: 519 KB
- Stars: 13
- Watchers: 4
- Forks: 10
- Open Issues: 7
-
Metadata Files:
- Readme: README.md
- Contributing: CONTRIBUTING.md
- License: LICENSE
- Codeowners: CODEOWNERS
- Security: SECURITY.md
Awesome Lists containing this project
README
# STACKIT Webhook Integration for Cert Manager
[](https://github.com/golang-standards/project-layout)
[](https://golang.org/)
[](https://helm.sh/)
[](https://kubernetes.io/)
[](https://cert-manager.io/)
[](https://github.com/stackitcloud/stackit-cert-manager-webhook/releases)
[](https://github.com/stackitcloud/stackit-cert-manager-webhook/actions/workflows/main.yml)
[](https://goreportcard.com/report/github.com/stackitcloud/stackit-cert-manager-webhook)
Facilitate a webhook integration for leveraging the STACKIT DNS alongside
its [API](https://docs.api.stackit.cloud/documentation/dns/version/v1) to act as a DNS01
ACME Issuer with [cert-manager](https://cert-manager.io/docs/).
## Installation
```bash
helm repo add stackit-cert-manager-webhook https://stackitcloud.github.io/stackit-cert-manager-webhook
helm install stackit-cert-manager-webhook --namespace cert-manager stackit-cert-manager-webhook/stackit-cert-manager-webhook
```
## Usage
1. ***Initiation of STACKIT Service Account Secret:***
```bash
kubectl create secret generic stackit-sa-authentication \
-n cert-manager \
--from-literal=sa.json='{
"id": "4e1fe486-b463-4bcd-9210-288854268e34",
"publicKey": "-----BEGIN PUBLIC KEY-----\nPUBLIC_KEY\n-----END PUBLIC KEY-----",
"createdAt": "2024-04-02T13:12:17.678+00:00",
"validUntil": "2024-04-15T22:00:00.000+00:00",
"keyType": "USER_MANAGED",
"keyOrigin": "GENERATED",
"keyAlgorithm": "RSA_2048",
"active": true,
"credentials": {
"kid": "kid",
"iss": "iss",
"sub": "sub",
"aud": "aud",
"privateKey": "-----BEGIN PRIVATE KEY-----\nPRIVATE-KEY==\n-----END PRIVATE KEY-----"
}
}'
```
You now need to adjust the deployment via helm to use the secret:
```bash
helm upgrade stackit-cert-manager-webhook \
--namespace cert-manager \
stackit-cert-manager-webhook/stackit-cert-manager-webhook \
--set stackitSaAuthentication.enabled=true
```
2. ***Configuration of ClusterIssuer/Issuer:***
For scenarios wherein zones and record sets are encapsulated within a singular project, utilize a ClusterIssuer:
```yaml
apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
name: letsencrypt-prod
spec:
acme:
server: https://acme-v02.api.letsencrypt.org/directory
email: example@example.com # Replace this with your email address
privateKeySecretRef:
name: letsencrypt-prod
solvers:
- dns01:
webhook:
solverName: stackit
groupName: acme.stackit.de
config:
projectId:
```
For diverse project architectures where zones are spread across varying projects, use an Issuer (namespaces are separate):
```yaml
apiVersion: cert-manager.io/v1
kind: Issuer
metadata:
name: letsencrypt-prod
namespace: default
spec:
acme:
server: https://acme-v02.api.letsencrypt.org/directory
email: example@example.com # Replace this with your email address
privateKeySecretRef:
name: letsencrypt-prod
solvers:
- dns01:
webhook:
solverName: stackit
groupName: acme.stackit.de
config:
projectId:
```
*Note on service accounts and namespaces:*
- Issuer-per-namespace (recommended for isolation): create a STACKIT service-account key (sa.json) for each STACKIT project you need to manage and place that key in a Kubernetes Secret in the same namespace as the Issuer. This means one sa.json (one SA key) per Issuer/namespace when the Issuers target different STACKIT projects.
Example (create a secret in the Issuer namespace):
```bash
kubectl create secret generic stackit-sa-authentication \
-n \
--from-literal=sa.json='{"id":"...","credentials":{...}}'
```
Ensure the webhook can read the secret in that namespace (create the secret where the Issuer lives).
- Alternative (single SA key for multiple projects): you can grant the service account broader permissions at folder or organization level so one sa.json can manage zones across multiple projects. This is more convenient but grants wider access — evaluate security and follow least-privilege principles.
- Tradeoffs:
- Per-namespace/per-project SA keys: better isolation and least privilege, easier to rotate keys per project.
- Folder/org-level SA key: lower operational overhead (single key), but larger blast radius if compromised.
3. ***Demonstration of Ingress Integration with Wildcard SSL/TLS Certificate Generation***
Given the preceding configuration, it is possible to exploit the capabilities of the Issuer or ClusterIssuer to
dynamically produce wildcard SSL/TLS certificates in the following manner:
```yaml
apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
name: wildcard-example
namespace: default
spec:
secretName: wildcard-example-tls
issuerRef:
name: letsencrypt-prod
kind: Issuer
commonName: '*.example.runs.onstackit.cloud' # project must be the owner of this zone
duration: 8760h0m0s
dnsNames:
- example.runs.onstackit.cloud
- '*.example.runs.onstackit.cloud'
---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: app-ingress
namespace: default
annotations:
ingress.kubernetes.io/rewrite-target: /
kubernetes.io/ingress.class: "nginx"
spec:
rules:
- host: "app.example.runs.onstackit.cloud"
http:
paths:
- path: /
pathType: Prefix
backend:
service:
name: webapp
port:
number: 80
tls:
- hosts:
- "app.example.runs.onstackit.cloud"
secretName: wildcard-example-tls
```
## Config Options
The following table delineates the configuration options available for the STACKIT Cert Manager Webhook:
```yaml
apiVersion: cert-manager.io/v1
kind: Issuer
metadata:
name: letsencrypt-prod
namespace: default
spec:
acme:
server: https://acme-v02.api.letsencrypt.org/directory
email: example@example.com # Replace this with your email address
privateKeySecretRef:
name: letsencrypt-prod
solvers:
- dns01:
webhook:
solverName: stackit
groupName: acme.stackit.de
config:
projectId: string
apiBasePath: string
serviceAccountKeyPath: string
serviceAccountBaseUrl: string
acmeTxtRecordTTL: int64
```
- projectId: The unique identifier for the STACKIT project.
- apiBasePath: The base path for the STACKIT DNS API. (Default: https://dns.api.stackit.cloud)
- serviceAccountKeyPath: The path to the service account key file. The file must be mounted into the container.
- serviceAccountBaseUrl: The base URL for the STACKIT service account API. (Default: https://service-account.api.stackit.cloud/token)
- acmeTxtRecordTTL: The TTL for the ACME TXT record. (Default: 600)
## Test Procedures
- Unit Testing:
```bash
make test
```
- Unit Testing with Coverage Analysis:
```bash
make coverage
```
- Linting:
```bash
make lint
```
- End-to-End Testing Workflow:
Follow the comprehensive guide available [here](e2e_test/README.md).
## Release Process Overview
Our release pipeline leverages goreleaser for the generation and publishing of release assets.
This sophisticated approach ensures the streamlined delivery of:
- Pre-compiled binaries tailored for various platforms.
- Docker images optimized for production readiness.
However, one should be cognizant of the fact that goreleaser doesn't inherently support Helm chart distributions
as part of its conventional workflow. Historically, the incorporation of Helm charts into our releases demanded manual
intervention. Post the foundational release generation via goreleaser, the Helm chart was affixed as an asset through
manual processes.
For those interested in the Helm chart creation mechanics, the process was facilitated via the command:
```bash
helm package deploy/stackit
```
To release a new version of the Helm chart, one must meticulously update the appVersion and (chart)version delineation in the
[Chart.yaml](./deploy/stackit/Chart.yaml). Post this modification, initiate a new release to encompass these changes.