Problem
dstack-ingress issues certs via ACME DNS-01, which requires a DNS provider API token that can edit the served domain's own zone (to write the _acme-challenge TXT, and — per entrypoint.sh — to set the A record and CAA).
In our deployment the served name (e.g. svc.example.com) lives under a shared production zone (example.com) that holds many unrelated production records. Handing the enclave a token for that zone is too broad:
- Cloudflare API tokens scope only to zone level — there is no way to restrict a token to a single subdomain/record.
- Managing the subdomain as its own Cloudflare zone requires an Enterprise plan.
So today we'd have to give the enclave a token that can edit our entire example.com zone, which we can't accept.
Proposed feature: DNS-01 challenge delegation (CNAME alias)
Let the operator delegate only the _acme-challenge to a separate zone they fully control, so the enclave's token never touches the production zone:
- Operator adds one static record in the production zone:
_acme-challenge.svc.example.com CNAME <label>.<delegation-zone>
- dstack-ingress writes the challenge TXT into
<delegation-zone> (its token scoped only to that zone). Let's Encrypt follows the CNAME during validation.
This is a standard least-privilege ACME pattern (acme.sh --challenge-alias, lego, cert-manager, and Cloudflare's own "Delegated DCV" all support it), and it fits dstack's zero-trust ethos.
Design sketch (opt-in, non-breaking)
- New env
ACME_CHALLENGE_ALIAS=<delegation-zone>; unset ⇒ current behavior, unchanged.
- When set, run certbot with
--manual --preferred-challenges=dns + auth/cleanup hooks that reuse the existing dns_providers abstraction to write the TXT under the alias zone instead of _acme-challenge.<domain>.
Important: CAA handling (needs an explicit decision)
entrypoint.sh currently auto-sets the accounturi CAA
(letsencrypt.org;validationmethods=dns-01;accounturi=$ACCOUNT_URI) on the served domain, using the same token. In delegation mode the token cannot touch the served domain's zone, so this auto-set won't work — and the current code treats a CAA-set failure as not critical, which would silently drop the accounturi lock (the forge-prevention against a non-TEE account issuing a cert for the domain).
To avoid silently weakening security, in delegation mode the feature should:
- print the exact CAA record the operator must set statically in the served zone (including the account URI), and
- verify the CAA is present / warn loudly if absent, instead of silently continuing.
This keeps the "only the TEE's ACME account can issue" guarantee explicit, rather than silently lost.
Problem
dstack-ingress issues certs via ACME DNS-01, which requires a DNS provider API token that can edit the served domain's own zone (to write the
_acme-challengeTXT, and — perentrypoint.sh— to set the A record and CAA).In our deployment the served name (e.g.
svc.example.com) lives under a shared production zone (example.com) that holds many unrelated production records. Handing the enclave a token for that zone is too broad:So today we'd have to give the enclave a token that can edit our entire
example.comzone, which we can't accept.Proposed feature: DNS-01 challenge delegation (CNAME alias)
Let the operator delegate only the
_acme-challengeto a separate zone they fully control, so the enclave's token never touches the production zone:_acme-challenge.svc.example.com CNAME <label>.<delegation-zone><delegation-zone>(its token scoped only to that zone). Let's Encrypt follows the CNAME during validation.This is a standard least-privilege ACME pattern (acme.sh
--challenge-alias, lego, cert-manager, and Cloudflare's own "Delegated DCV" all support it), and it fits dstack's zero-trust ethos.Design sketch (opt-in, non-breaking)
ACME_CHALLENGE_ALIAS=<delegation-zone>; unset ⇒ current behavior, unchanged.--manual --preferred-challenges=dns+ auth/cleanup hooks that reuse the existingdns_providersabstraction to write the TXT under the alias zone instead of_acme-challenge.<domain>.Important: CAA handling (needs an explicit decision)
entrypoint.shcurrently auto-sets the accounturi CAA(
letsencrypt.org;validationmethods=dns-01;accounturi=$ACCOUNT_URI) on the served domain, using the same token. In delegation mode the token cannot touch the served domain's zone, so this auto-set won't work — and the current code treats a CAA-set failure asnot critical, which would silently drop the accounturi lock (the forge-prevention against a non-TEE account issuing a cert for the domain).To avoid silently weakening security, in delegation mode the feature should:
This keeps the "only the TEE's ACME account can issue" guarantee explicit, rather than silently lost.