Kubernetes
Two integrations cover most clusters: cert-manager issuing certificates through the DNS-01 challenge, and external-dns keeping records in sync with your Ingress objects.
Start with a narrow key
Do not hand a cluster a full-access key. Issue one restricted to the zones it needs with allowed_zone_ids, and — for certificate renewal — use the acme scope,
which can only create and delete the TXT record at _acme-challenge.
curl -X POST 'https://api.qflaryx.com/v1/orgs/$ORG_ID/api-keys' \
-H 'Authorization: Bearer $SESSION_TOKEN' \
-H 'Content-Type: application/json' \
-d '{"scopes": ["acme"], "allowed_zone_ids": [123]}'secret exactly once. Put it straight into a Kubernetes Secret —
there is no way to read it again.cert-manager over DNS-01
The safest setup delegates only the challenge label, so the cluster never writes into the zone it is proving. Create this CNAME once, by hand:
_acme-challenge.app.example.com. CNAME _acme-challenge.example.com.From then on cert-manager writes the TXT at _acme-challenge.example.com using the acme-scoped key. Store the key like this:
apiVersion: v1
kind: Secret
metadata:
name: quathos-monitor-acme
namespace: cert-manager
stringData:
api-key: qfx_1a2b3c4d_your-secret-hereexternal-dns
external-dns needs to read and write records, so it takes record:read and record:write — still restricted to the zones that cluster owns. A cluster serving one
domain has no reason to be able to rewrite the others.
curl -X POST 'https://api.qflaryx.com/v1/orgs/$ORG_ID/api-keys' \
-H 'Authorization: Bearer $SESSION_TOKEN' \
-H 'Content-Type: application/json' \
-d '{"scopes": ["record:read", "record:write"], "allowed_zone_ids": [123]}'Rate limits
Requests are counted per organization per hour, according to your plan. On the ceiling the API
answers 429 with a Retry-After header; honour it instead of retrying
immediately and your controller settles on its own.