Hacktoberfest 2026:维护者为十月标记出来的 issue,仍然开放、适合新手。 浏览 Hacktoberfest issue

Feature: ACME DNS-01 challenge delegation (CNAME alias) for least-privilege DNS tokens

未关闭
#103 1 条评论 0 个 reaction 已指派 0 人 在 GitHub 查看

维护者通常 1 天内回复

还没有人认领这个 Issue。

评估

难度
5/5
预计耗时
一周以上
新手友好度
45/100
Issue 类型
功能
描述清晰度
基本清楚
活跃度
冷清
技术栈
python, shell
领域
cloud, devops, security

调研方向

从 entrypoint.sh 和现有的 dns_providers 抽象开始;跟踪当前的 ACME 调用、TXT 处理和 CAA 失败路径。检查提议的 ACME_CHALLENGE_ALIAS 流程以及 certbot 的 manual auth/cleanup hooks。完成的标准是:alias-zone 的 TXT 委派无需访问 production-zone 即可正常工作,同时准确的 accounturi CAA 会被打印并验证,或者明确报告其缺失。

由索引模型根据 Issue 内容生成。

描述

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:

  1. Operator adds one static record in the production zone:
    _acme-challenge.svc.example.com CNAME <label>.<delegation-zone>
  2. 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.

主要语言
Python
星标
27
派生
26
平均合并
1 天 6 小时
30 天内合并 PR
12

环境准备

从这里开始

  1. 先读完整个 Issue,再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库,在一个分支上完成修改。
  4. 提交 Pull Request,并在描述里引用这个 Issue 编号。

Dstack-TEE/dstack-examples 的其他 Issue

查看 Dstack-TEE/dstack-examples 的全部 Issue

相似的 Issue

更多 Python Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。