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.

Keys are issued with your dashboard session ($SESSION_TOKEN below) by an owner or admin of the organization:

curl -X POST "https://api.monitor.quathos.com/v1/orgs/$ORG_ID/api-keys" \
  -H "Authorization: Bearer $SESSION_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"scopes": ["acme"], "allowed_zone_ids": [123]}'

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-here

external-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.monitor.quathos.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 rate_limited with a Retry-After header; honour it instead of retrying immediately and your controller settles on its own.