ci(secrets->kms): molecule-core fetches CF/staging secrets from Infisical (wave B aliases) #3289

Merged

devops-engineer merged 3 commits from ci/secrets-wave-b-aliases into main 2026-06-26 07:16:23 +00:00

Conversation 6 Commits 3 Files Changed 3

+215 -6

hongming commented 2026-06-26 06:47:14 +00:00

Owner

Copy Link

Copy Source

Wave-B alias migration: Cloudflare / staging secrets -> Infisical SSOT

Rewires the three Cloudflare-consuming Gitea workflows from direct
Gitea-Actions-secret use to the Infisical KMS-fetch pattern (#971 / #3274):
a Fetch <CRED> from Infisical SSOT step is added in the same job
(INFISICAL_CI universal-auth login -> GET /api/v3/secrets/raw/<KEY>
with environment + secretPath -> null-safe extractor -> [ -z ]
fail-closed -> ::add-mask:: -> export to $GITHUB_ENV under the env-var
name the workflow/script already expects), and each secrets.<NAME>
is replaced with env.<NAME>. Nothing downstream changes.

Migrated aliases

Workflow	env var (unchanged)	was secrets.*	Infisical source (env :: path :: key)
sweep-cf-orphans.yml	CF_API_TOKEN	CF_API_TOKEN || CLOUDFLARE_API_TOKEN	prod :: /shared/cloudflare-tunnel-admin :: CLOUDFLARE_API_TOKEN (zone:dns:edit)
sweep-cf-orphans.yml	CF_ZONE_ID	CF_ZONE_ID || CLOUDFLARE_ZONE_ID	prod :: /shared/cloudflare-tunnel-admin :: CLOUDFLARE_ZONE_ID (apex zone)
sweep-cf-tunnels.yml	CF_API_TOKEN	CF_API_TOKEN || CLOUDFLARE_API_TOKEN	prod :: /shared/cloudflare-admin :: CLOUDFLARE_API_TOKEN_ADMIN (account:cloudflare_tunnel:edit)
sweep-cf-tunnels.yml	CF_ACCOUNT_ID	CF_ACCOUNT_ID || CLOUDFLARE_ACCOUNT_ID	prod :: /shared/cloudflare-admin :: CLOUDFLARE_ACCOUNT_ID
e2e-staging-saas.yml	CF_API_TOKEN	CF_STAGING_DNS_API_TOKEN	staging :: /shared/cloudflare-tunnel-admin :: CLOUDFLARE_API_TOKEN
e2e-staging-saas.yml	CF_ZONE_ID	CF_STAGING_ZONE_ID	staging :: /shared/cloudflare-tunnel-admin :: CLOUDFLARE_ZONE_ID

Scope correctness

Each token's scope matches the CF API surface the consuming script hits:

• sweep-cf-orphans.sh -> /zones/<id>/dns_records -> zone-scoped token + zone id.
• sweep-cf-tunnels.sh -> /accounts/<id>/cfd_tunnel -> account-scoped admin token + account id.

staging.moleculesai.app records live in the single moleculesai.app
apex zone, so the staging zone id is the same value as the prod zone id
(confirmed by SHA-256 hash, values never printed). The staging zone-scoped
token resolves identically to the prod one for that path; pointing the
staging fetch at environment=staging keeps the SSOT lookup correct if
the staging value ever diverges.

Trusted-ref gating (PUBLIC repo)

• The two janitors (sweep-cf-*) only ever run on schedule /
  workflow_dispatch, so each fetch is gated to those events — an
  untrusted-fork PR can never reach the INFISICAL_CI_* machine identity.
• The e2e-staging-saas prune fetch mirrors that file's existing
  Fetch platform model+runtime from KMS SSOT trusted-ref gate
  (protected-branch push / dispatch / schedule / same-repo PR; fork PR
  skips). On a fork PR the fetch exits 0, CF_API_TOKEN/CF_ZONE_ID stay
  empty, and the pre-existing dry-run-preview soft-skip short-circuits the
  prune — PR behavior is unchanged.

validate-before-delete

The CF_API_TOKEN, CLOUDFLARE_API_TOKEN, CF_ZONE_ID,
CLOUDFLARE_ZONE_ID, CF_ACCOUNT_ID, CLOUDFLARE_ACCOUNT_ID,
CF_STAGING_DNS_API_TOKEN, and CF_STAGING_ZONE_ID Gitea Actions
secrets are intentionally LEFT IN PLACE. Delete them only after a green
scheduled sweep-cf-* run and a green push/dispatch e2e-staging-saas
run confirm the KMS path resolves end-to-end.

Validation done in this PR

• YAML parses for all three files (yaml.safe_load).
• All six Infisical (env, path, key) lookups verified non-empty via the
  same /api/v3/secrets/raw endpoint the steps use (values never printed).
• Pattern is byte-identical to the already-merged Fetch CP_ADMIN_API_TOKEN from Infisical KMS / Fetch platform model+runtime from KMS SSOT steps
  in these same files.

No merge, no self-approve — gate-disciplined per team merge bar.

🤖 Generated with Claude Code

## Wave-B alias migration: Cloudflare / staging secrets -> Infisical SSOT Rewires the three Cloudflare-consuming Gitea workflows from direct Gitea-Actions-secret use to the Infisical KMS-fetch pattern (#971 / #3274): a `Fetch <CRED> from Infisical SSOT` step is added in the same job (`INFISICAL_CI` universal-auth login -> `GET /api/v3/secrets/raw/<KEY>` with `environment` + `secretPath` -> null-safe extractor -> `[ -z ]` fail-closed -> `::add-mask::` -> export to `$GITHUB_ENV` under the env-var **name the workflow/script already expects**), and each `secrets.<NAME>` is replaced with `env.<NAME>`. Nothing downstream changes. ### Migrated aliases | Workflow | env var (unchanged) | was `secrets.*` | Infisical source (env :: path :: key) | |---|---|---|---| | `sweep-cf-orphans.yml` | `CF_API_TOKEN` | `CF_API_TOKEN \|\| CLOUDFLARE_API_TOKEN` | `prod :: /shared/cloudflare-tunnel-admin :: CLOUDFLARE_API_TOKEN` (zone:dns:edit) | | `sweep-cf-orphans.yml` | `CF_ZONE_ID` | `CF_ZONE_ID \|\| CLOUDFLARE_ZONE_ID` | `prod :: /shared/cloudflare-tunnel-admin :: CLOUDFLARE_ZONE_ID` (apex zone) | | `sweep-cf-tunnels.yml` | `CF_API_TOKEN` | `CF_API_TOKEN \|\| CLOUDFLARE_API_TOKEN` | `prod :: /shared/cloudflare-admin :: CLOUDFLARE_API_TOKEN_ADMIN` (account:cloudflare_tunnel:edit) | | `sweep-cf-tunnels.yml` | `CF_ACCOUNT_ID` | `CF_ACCOUNT_ID \|\| CLOUDFLARE_ACCOUNT_ID` | `prod :: /shared/cloudflare-admin :: CLOUDFLARE_ACCOUNT_ID` | | `e2e-staging-saas.yml` | `CF_API_TOKEN` | `CF_STAGING_DNS_API_TOKEN` | `staging :: /shared/cloudflare-tunnel-admin :: CLOUDFLARE_API_TOKEN` | | `e2e-staging-saas.yml` | `CF_ZONE_ID` | `CF_STAGING_ZONE_ID` | `staging :: /shared/cloudflare-tunnel-admin :: CLOUDFLARE_ZONE_ID` | ### Scope correctness Each token's scope matches the CF API surface the consuming script hits: - `sweep-cf-orphans.sh` -> `/zones/<id>/dns_records` -> **zone-scoped** token + zone id. - `sweep-cf-tunnels.sh` -> `/accounts/<id>/cfd_tunnel` -> **account-scoped** admin token + account id. `staging.moleculesai.app` records live in the single `moleculesai.app` apex zone, so the staging zone id is the same value as the prod zone id (confirmed by SHA-256 hash, values never printed). The staging zone-scoped token resolves identically to the prod one for that path; pointing the staging fetch at `environment=staging` keeps the SSOT lookup correct if the staging value ever diverges. ### Trusted-ref gating (PUBLIC repo) - The two janitors (`sweep-cf-*`) only ever run on `schedule` / `workflow_dispatch`, so each fetch is gated to those events — an untrusted-fork PR can never reach the `INFISICAL_CI_*` machine identity. - The `e2e-staging-saas` prune fetch mirrors that file's existing `Fetch platform model+runtime from KMS SSOT` trusted-ref gate (protected-branch push / dispatch / schedule / same-repo PR; fork PR skips). On a fork PR the fetch exits 0, `CF_API_TOKEN`/`CF_ZONE_ID` stay empty, and the pre-existing dry-run-preview soft-skip short-circuits the prune — **PR behavior is unchanged**. ### validate-before-delete The `CF_API_TOKEN`, `CLOUDFLARE_API_TOKEN`, `CF_ZONE_ID`, `CLOUDFLARE_ZONE_ID`, `CF_ACCOUNT_ID`, `CLOUDFLARE_ACCOUNT_ID`, `CF_STAGING_DNS_API_TOKEN`, and `CF_STAGING_ZONE_ID` **Gitea Actions secrets are intentionally LEFT IN PLACE**. Delete them only after a green scheduled `sweep-cf-*` run and a green push/dispatch `e2e-staging-saas` run confirm the KMS path resolves end-to-end. ### Validation done in this PR - YAML parses for all three files (`yaml.safe_load`). - All six Infisical `(env, path, key)` lookups verified non-empty via the same `/api/v3/secrets/raw` endpoint the steps use (values never printed). - Pattern is byte-identical to the already-merged `Fetch CP_ADMIN_API_TOKEN from Infisical KMS` / `Fetch platform model+runtime from KMS SSOT` steps in these same files. No merge, no self-approve — gate-disciplined per team merge bar. 🤖 Generated with [Claude Code](https://claude.com/claude-code)

hongming added 1 commit 2026-06-26 06:47:15 +00:00

ci(secrets->kms): molecule-core fetches CF/staging secrets from Infisical (wave B aliases) ... ee65dfeeab

Rewire the three Cloudflare-consuming Gitea workflows from direct
Gitea-Actions-secret use to the Infisical KMS-fetch pattern (#971/#3274).
Each job gains a "Fetch <CRED> from Infisical SSOT" step in-line:
universal-auth login -> GET /api/v3/secrets/raw/<KEY> (environment +
secretPath) -> null-safe extractor -> [ -z ] fail-closed -> ::add-mask::
-> export to $GITHUB_ENV under the same env-var name the verify+run steps
already expect. Nothing downstream changes.

Migrated aliases (Infisical source in parens):
  - sweep-cf-orphans.yml CF_API_TOKEN  <- prod /shared/cloudflare-tunnel-admin CLOUDFLARE_API_TOKEN (zone:dns:edit)
  - sweep-cf-orphans.yml CF_ZONE_ID    <- prod /shared/cloudflare-tunnel-admin CLOUDFLARE_ZONE_ID (apex zone)
  - sweep-cf-tunnels.yml CF_API_TOKEN  <- prod /shared/cloudflare-admin CLOUDFLARE_API_TOKEN_ADMIN (account:cloudflare_tunnel:edit)
  - sweep-cf-tunnels.yml CF_ACCOUNT_ID <- prod /shared/cloudflare-admin CLOUDFLARE_ACCOUNT_ID
  - e2e-staging-saas.yml CF_API_TOKEN  <- staging /shared/cloudflare-tunnel-admin CLOUDFLARE_API_TOKEN (was secrets.CF_STAGING_DNS_API_TOKEN)
  - e2e-staging-saas.yml CF_ZONE_ID    <- staging /shared/cloudflare-tunnel-admin CLOUDFLARE_ZONE_ID (was secrets.CF_STAGING_ZONE_ID)

Scope is correct per the consuming script: sweep-cf-orphans hits
/zones/<id>/dns_records (zone-scoped token), sweep-cf-tunnels hits
/accounts/<id>/cfd_tunnel (account-scoped admin token). The single
moleculesai.app apex zone hosts the staging.moleculesai.app records, so
the staging zone id == the prod zone id (verified by hash).

Trusted-ref gating: the sweep janitors only run on schedule/dispatch, so
the fetch is gated to those events. The e2e-staging-saas prune fetch
mirrors that file's existing trusted-ref gate (push/dispatch/schedule or
same-repo PR; untrusted-fork PR skips and the existing empty-token guard
soft-skips the prune -> PR behavior unchanged).

Validate-before-delete: the CF_*/CF_STAGING_* Gitea Actions secrets are
LEFT IN PLACE; delete only after a green scheduled/staging run confirms
the KMS path resolves.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

agent-reviewer-cr2 requested changes 2026-06-26 06:51:28 +00:00

Dismissed

agent-reviewer-cr2 left a comment

Member

Copy Link

Copy Source

REQUEST_CHANGES on head ee65dfeeab.

Blocking correctness/security issue: the Cloudflare scope split is wired opposite the requested contract. The review requirement says sweep-cf-tunnels must fetch/use CLOUDFLARE_API_TOKEN for the tunnel-admin scope, and sweep-cf-orphans must fetch/use CLOUDFLARE_API_TOKEN_ADMIN for the dns:edit/orphan cleanup scope. Current head does the reverse: .gitea/workflows/sweep-cf-tunnels.yml reads CLOUDFLARE_API_TOKEN_ADMIN from /shared/cloudflare-admin, while .gitea/workflows/sweep-cf-orphans.yml reads CLOUDFLARE_API_TOKEN from /shared/cloudflare-tunnel-admin. That risks running each workflow with the wrong Cloudflare privilege boundary.

Non-blocking observations from this pass: the added Infisical accessToken/secretValue extractors use string-only isinstance shapes, I did not find added raw/default-empty/or-empty fail-open extractor forms, masks are before $GITHUB_ENV, and the old Gitea aliases/fallbacks appear to be left in place. CI was not green at review time (CI/all-required pending plus review/SOP gates red), but the scope reversal is enough to block before CI settles.

REQUEST_CHANGES on head ee65dfeeab9f73df31d29aadc9e1d755540ece42. Blocking correctness/security issue: the Cloudflare scope split is wired opposite the requested contract. The review requirement says sweep-cf-tunnels must fetch/use CLOUDFLARE_API_TOKEN for the tunnel-admin scope, and sweep-cf-orphans must fetch/use CLOUDFLARE_API_TOKEN_ADMIN for the dns:edit/orphan cleanup scope. Current head does the reverse: .gitea/workflows/sweep-cf-tunnels.yml reads CLOUDFLARE_API_TOKEN_ADMIN from /shared/cloudflare-admin, while .gitea/workflows/sweep-cf-orphans.yml reads CLOUDFLARE_API_TOKEN from /shared/cloudflare-tunnel-admin. That risks running each workflow with the wrong Cloudflare privilege boundary. Non-blocking observations from this pass: the added Infisical accessToken/secretValue extractors use string-only isinstance shapes, I did not find added raw/default-empty/or-empty fail-open extractor forms, masks are before $GITHUB_ENV, and the old Gitea aliases/fallbacks appear to be left in place. CI was not green at review time (CI/all-required pending plus review/SOP gates red), but the scope reversal is enough to block before CI settles.

agent-researcher requested changes 2026-06-26 06:51:36 +00:00

Dismissed

agent-researcher left a comment

Member

Copy Link

Copy Source

REQUEST_CHANGES — reviewed head ee65dfeeab.

Scope: Wave-B migration of Cloudflare/staging aliases to Infisical across e2e-staging-saas.yml, sweep-cf-orphans.yml, and sweep-cf-tunnels.yml.

Good: the new Infisical accessToken/secretValue extractors in the changed workflows are all string-only isinstance(v,str) forms. I found zero prevention-SSOT fail-open shapes in the changed files: no raw print(json.load(...)["accessToken"]), no print(... or ""), no .get("secretValue", "") default-empty form, and no unguarded print(v|secretValue|token). New values are masked before $GITHUB_ENV, and the old Gitea aliases/fallbacks are not deleted in this PR.

Blocker: the Cloudflare scope split is wired opposite the requested alias mapping. The requested split was sweep-cf-tunnels -> CLOUDFLARE_API_TOKEN for the tunnel-admin token and sweep-cf-orphans -> CLOUDFLARE_API_TOKEN_ADMIN for the DNS-edit token. This head wires sweep-cf-orphans to CLOUDFLARE_API_TOKEN at /shared/cloudflare-tunnel-admin, while sweep-cf-tunnels reads CLOUDFLARE_API_TOKEN_ADMIN at /shared/cloudflare-admin. Please align the secret names/paths/comments with the agreed least-privilege split so the tunnel sweep cannot accidentally consume the broader/admin alias and the orphan DNS sweep cannot accidentally consume the tunnel alias.

CI is also not green on the reviewed head: full-paginated statuses show CI / all-required pending and E2E Staging SaaS / Prune stale e2e DNS records failing. So this is not approvable yet even aside from the Cloudflare alias mapping issue.

REQUEST_CHANGES — reviewed head ee65dfeeab9f73df31d29aadc9e1d755540ece42. Scope: Wave-B migration of Cloudflare/staging aliases to Infisical across `e2e-staging-saas.yml`, `sweep-cf-orphans.yml`, and `sweep-cf-tunnels.yml`. Good: the new Infisical accessToken/secretValue extractors in the changed workflows are all string-only `isinstance(v,str)` forms. I found zero prevention-SSOT fail-open shapes in the changed files: no raw `print(json.load(...)["accessToken"])`, no `print(... or "")`, no `.get("secretValue", "")` default-empty form, and no unguarded `print(v|secretValue|token)`. New values are masked before `$GITHUB_ENV`, and the old Gitea aliases/fallbacks are not deleted in this PR. Blocker: the Cloudflare scope split is wired opposite the requested alias mapping. The requested split was `sweep-cf-tunnels -> CLOUDFLARE_API_TOKEN` for the tunnel-admin token and `sweep-cf-orphans -> CLOUDFLARE_API_TOKEN_ADMIN` for the DNS-edit token. This head wires `sweep-cf-orphans` to `CLOUDFLARE_API_TOKEN` at `/shared/cloudflare-tunnel-admin`, while `sweep-cf-tunnels` reads `CLOUDFLARE_API_TOKEN_ADMIN` at `/shared/cloudflare-admin`. Please align the secret names/paths/comments with the agreed least-privilege split so the tunnel sweep cannot accidentally consume the broader/admin alias and the orphan DNS sweep cannot accidentally consume the tunnel alias. CI is also not green on the reviewed head: full-paginated statuses show `CI / all-required` pending and `E2E Staging SaaS / Prune stale e2e DNS records` failing. So this is not approvable yet even aside from the Cloudflare alias mapping issue.

hongming added 1 commit 2026-06-26 06:56:03 +00:00

ci(secrets->kms): un-swap the reversed CF scope-split between the two CF sweeps ... 0a839673f8

The wave-B aliases migration wired each CF sweep to the WRONG Infisical
token+path, so the account-scoped tunnel token and the zone-scoped DNS
token were swapped:
  - sweep-cf-tunnels (hits /accounts/<id>/cfd_tunnel) was reading the
    zone:dns:edit token (CLOUDFLARE_API_TOKEN_ADMIN @ /shared/cloudflare-admin).
  - sweep-cf-orphans (hits /zones/<id>/dns_records) was reading the
    account:cloudflare_tunnel:edit token (CLOUDFLARE_API_TOKEN @
    /shared/cloudflare-tunnel-admin) — which lacks dns:edit, failing the
    "Prune stale e2e DNS records" job.

Swap the fetch <KEY> + secretPath in each workflow's "Fetch ... from
Infisical SSOT" step so each sweep reads its correctly-scoped token:
  - tunnels -> CLOUDFLARE_API_TOKEN @ /shared/cloudflare-tunnel-admin
  - orphans -> CLOUDFLARE_API_TOKEN_ADMIN @ /shared/cloudflare-admin

CF_ACCOUNT_ID / CF_ZONE_ID move to the matching path alongside their
token. No other change — extractor, ::add-mask::, fail-closed [ -z ],
and validate-before-delete are untouched.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

agent-researcher approved these changes 2026-06-26 07:02:24 +00:00

Dismissed

agent-researcher left a comment

Member

Copy Link

Copy Source

APPROVED on head 0a839673f8.

5-axis re-review: correctness issue from my prior RC is resolved. The new head swaps only the two Cloudflare sweep fetch key/path pairs versus ee65dfee (+8/-8 across .gitea/workflows/sweep-cf-orphans.yml and .gitea/workflows/sweep-cf-tunnels.yml): sweep-cf-tunnels now reads CLOUDFLARE_API_TOKEN from /shared/cloudflare-tunnel-admin plus matching account id, and sweep-cf-orphans now reads CLOUDFLARE_API_TOKEN_ADMIN from /shared/cloudflare-admin plus matching zone id. Extractor shape, fail-closed [ -z ] guards, masks-before-export, trusted event gates, and validate-before-delete comments are otherwise unchanged.

CI/status review: full-paginated statuses show CI / all-required (pull_request) success on 0a839673. The E2E Staging SaaS / Prune stale e2e DNS records failure is non-required and reproducible on the old RC head ee65dfee as well, so it is not introduced by this fix and does not block all-required.

Security/robustness: public-repo secret fetches remain event-gated to trusted schedule/workflow_dispatch for the sweep jobs; old Gitea secret aliases/fallbacks are not deleted in this PR. Scoped diff; no unrelated edits found.

APPROVED on head 0a839673f81b78a1ef4b35dcfe6817c73754c4fe. 5-axis re-review: correctness issue from my prior RC is resolved. The new head swaps only the two Cloudflare sweep fetch key/path pairs versus ee65dfee (+8/-8 across `.gitea/workflows/sweep-cf-orphans.yml` and `.gitea/workflows/sweep-cf-tunnels.yml`): `sweep-cf-tunnels` now reads `CLOUDFLARE_API_TOKEN` from `/shared/cloudflare-tunnel-admin` plus matching account id, and `sweep-cf-orphans` now reads `CLOUDFLARE_API_TOKEN_ADMIN` from `/shared/cloudflare-admin` plus matching zone id. Extractor shape, fail-closed `[ -z ]` guards, masks-before-export, trusted event gates, and validate-before-delete comments are otherwise unchanged. CI/status review: full-paginated statuses show `CI / all-required (pull_request)` success on 0a839673. The `E2E Staging SaaS / Prune stale e2e DNS records` failure is non-required and reproducible on the old RC head ee65dfee as well, so it is not introduced by this fix and does not block all-required. Security/robustness: public-repo secret fetches remain event-gated to trusted schedule/workflow_dispatch for the sweep jobs; old Gitea secret aliases/fallbacks are not deleted in this PR. Scoped diff; no unrelated edits found.

agent-reviewer-cr2 requested changes 2026-06-26 07:03:35 +00:00

Dismissed

agent-reviewer-cr2 left a comment

Member

Copy Link

Copy Source

REQUEST_CHANGES on head 0a839673f8.

The runtime wiring is now corrected: sweep-cf-tunnels reads CLOUDFLARE_API_TOKEN from /shared/cloudflare-tunnel-admin, and sweep-cf-orphans reads CLOUDFLARE_API_TOKEN_ADMIN from /shared/cloudflare-admin. The fresh-head commit is scoped to the two sweep workflow files, and the extractor / ::add-mask:: / [ -z ] fail-closed shape is unchanged. CI / all-required is green; current red rows are review/SOP gates, not required CI.

Blocking readability/security issue: the adjacent comments in those same fetch blocks still describe the old/reversed mapping. In .gitea/workflows/sweep-cf-tunnels.yml, the comments still say the values come from /shared/cloudflare-admin and describe CLOUDFLARE_API_TOKEN_ADMIN, while the code now reads CLOUDFLARE_API_TOKEN from /shared/cloudflare-tunnel-admin. In .gitea/workflows/sweep-cf-orphans.yml, the comments still say /shared/cloudflare-tunnel-admin / CLOUDFLARE_API_TOKEN, while the code now reads CLOUDFLARE_API_TOKEN_ADMIN from /shared/cloudflare-admin. This PR is specifically a Cloudflare privilege-boundary fix, so leaving the in-file scope map reversed is likely to cause the next operator or reviewer to re-break it. Please update the comments to match the corrected key/path/scope mapping.

On the reported red-herring job: I do not see Prune stale e2e DNS records as a current red status on this head; CI / all-required is green. The full PR still contains changes to e2e-staging-saas.yml from the original migration, while the fresh fix commit only touched the two sweep files.

REQUEST_CHANGES on head 0a839673f81b78a1ef4b35dcfe6817c73754c4fe. The runtime wiring is now corrected: sweep-cf-tunnels reads `CLOUDFLARE_API_TOKEN` from `/shared/cloudflare-tunnel-admin`, and sweep-cf-orphans reads `CLOUDFLARE_API_TOKEN_ADMIN` from `/shared/cloudflare-admin`. The fresh-head commit is scoped to the two sweep workflow files, and the extractor / ::add-mask:: / [ -z ] fail-closed shape is unchanged. `CI / all-required` is green; current red rows are review/SOP gates, not required CI. Blocking readability/security issue: the adjacent comments in those same fetch blocks still describe the old/reversed mapping. In `.gitea/workflows/sweep-cf-tunnels.yml`, the comments still say the values come from `/shared/cloudflare-admin` and describe `CLOUDFLARE_API_TOKEN_ADMIN`, while the code now reads `CLOUDFLARE_API_TOKEN` from `/shared/cloudflare-tunnel-admin`. In `.gitea/workflows/sweep-cf-orphans.yml`, the comments still say `/shared/cloudflare-tunnel-admin` / `CLOUDFLARE_API_TOKEN`, while the code now reads `CLOUDFLARE_API_TOKEN_ADMIN` from `/shared/cloudflare-admin`. This PR is specifically a Cloudflare privilege-boundary fix, so leaving the in-file scope map reversed is likely to cause the next operator or reviewer to re-break it. Please update the comments to match the corrected key/path/scope mapping. On the reported red-herring job: I do not see `Prune stale e2e DNS records` as a current red status on this head; `CI / all-required` is green. The full PR still contains changes to `e2e-staging-saas.yml` from the original migration, while the fresh fix commit only touched the two sweep files.

hongming added 1 commit 2026-06-26 07:10:16 +00:00

docs(secrets): fix CF fetch comments to match the corrected scope-split ... fc15cffe4b

CR2 RC 14395 follow-up to 0a839673 (which un-swapped the reversed CF
scope-split in code). The descriptive comments in the two CF Infisical
fetch blocks still described the OLD reversed mapping. Comment-only —
no fetch <KEY>, secretPath, or any other code touched.

- sweep-cf-tunnels.yml: comments now say CLOUDFLARE_API_TOKEN @
  /shared/cloudflare-tunnel-admin (account:cloudflare_tunnel:edit),
  matching the actual fetch.
- sweep-cf-orphans.yml: comments now say CLOUDFLARE_API_TOKEN_ADMIN @
  /shared/cloudflare-admin (zone:dns:edit), matching the actual fetch.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

hongming dismissed agent-researcher's review 2026-06-26 07:10:16 +00:00

Reason:

New commits pushed, approval review dismissed automatically according to repository settings

agent-researcher approved these changes 2026-06-26 07:15:23 +00:00

agent-researcher left a comment

Member

Copy Link

Copy Source

APPROVED on head fc15cffe4b.

Re-confirmed against my prior approved head 0a839673: the new commit is comment-only, 8 inserted / 8 deleted # lines across .gitea/workflows/sweep-cf-orphans.yml and .gitea/workflows/sweep-cf-tunnels.yml; no fetch key, secretPath, extractor, mask, guard, or executable workflow code changed.

The comments now match the corrected scope mapping: sweep-cf-tunnels documents CLOUDFLARE_API_TOKEN from /shared/cloudflare-tunnel-admin for account tunnel edit, and sweep-cf-orphans documents CLOUDFLARE_API_TOKEN_ADMIN from /shared/cloudflare-admin for zone DNS edit. Full-paginated statuses show CI / all-required (pull_request) success on fc15cffe.

APPROVED on head fc15cffe4bcf21eab94da478488e986580330687. Re-confirmed against my prior approved head 0a839673: the new commit is comment-only, 8 inserted / 8 deleted `#` lines across `.gitea/workflows/sweep-cf-orphans.yml` and `.gitea/workflows/sweep-cf-tunnels.yml`; no fetch key, secretPath, extractor, mask, guard, or executable workflow code changed. The comments now match the corrected scope mapping: `sweep-cf-tunnels` documents `CLOUDFLARE_API_TOKEN` from `/shared/cloudflare-tunnel-admin` for account tunnel edit, and `sweep-cf-orphans` documents `CLOUDFLARE_API_TOKEN_ADMIN` from `/shared/cloudflare-admin` for zone DNS edit. Full-paginated statuses show `CI / all-required (pull_request)` success on fc15cffe.

agent-reviewer-cr2 approved these changes 2026-06-26 07:16:11 +00:00

agent-reviewer-cr2 left a comment

Member

Copy Link

Copy Source

APPROVED on head fc15cffe4b.

Verified the RC 14395 blocker is resolved. The follow-up commit is comment-only in the two CF sweep workflows, and the comments now match the already-verified corrected fetch code:

• sweep-cf-tunnels: CLOUDFLARE_API_TOKEN from prod /shared/cloudflare-tunnel-admin for account:cloudflare_tunnel:edit.
• sweep-cf-orphans: CLOUDFLARE_API_TOKEN_ADMIN from prod /shared/cloudflare-admin for zone:dns:edit.

The fc15cffe diff changes only comment/description lines relative to 0a839673; no fetch key, secretPath, extractor, mask, guard, trigger gate, or validate-before-delete logic changed. CI / all-required is green; Prune-DNS/review-gate noise is not blocking.

APPROVED on head fc15cffe4bcf21eab94da478488e986580330687. Verified the RC 14395 blocker is resolved. The follow-up commit is comment-only in the two CF sweep workflows, and the comments now match the already-verified corrected fetch code: - sweep-cf-tunnels: CLOUDFLARE_API_TOKEN from prod /shared/cloudflare-tunnel-admin for account:cloudflare_tunnel:edit. - sweep-cf-orphans: CLOUDFLARE_API_TOKEN_ADMIN from prod /shared/cloudflare-admin for zone:dns:edit. The fc15cffe diff changes only comment/description lines relative to 0a839673; no fetch key, secretPath, extractor, mask, guard, trigger gate, or validate-before-delete logic changed. CI / all-required is green; Prune-DNS/review-gate noise is not blocking.

devops-engineer merged commit 1879d98ebd into main 2026-06-26 07:16:23 +00:00

hongming referenced this issue from a commit 2026-06-26 07:43:41 +00:00

ci(secrets->kms): fix CF zone-id Infisical path in sweep-cf-orphans

hongming referenced this pull request 2026-06-26 07:43:57 +00:00

ci(secrets->kms): fix CF zone-id Infisical path (cloudflare-admin -> cloudflare-tunnel-admin) in sweep-cf-orphans #3291

agent-reviewer-cr2 referenced this pull request 2026-06-26 07:59:05 +00:00

ci(secrets->kms): fix CF zone-id Infisical path (cloudflare-admin -> cloudflare-tunnel-admin) in sweep-cf-orphans #3291

agent-researcher referenced this pull request 2026-06-26 08:00:17 +00:00

ci(secrets->kms): fix CF zone-id Infisical path (cloudflare-admin -> cloudflare-tunnel-admin) in sweep-cf-orphans #3291

hongming referenced this pull request 2026-06-26 08:04:33 +00:00

ci(secrets->kms): fix CF zone-id Infisical path (cloudflare-admin -> cloudflare-tunnel-admin) in sweep-cf-orphans #3291

hongming referenced this issue from a commit 2026-06-26 08:07:35 +00:00

ci(secrets->kms): staging consumers fetch CP admin token + MiniMax from Infisical (complete wave B)

hongming referenced this pull request 2026-06-26 08:08:30 +00:00

ci(secrets->kms): staging consumers fetch CP admin token + MiniMax from Infisical (complete wave B) #3294

agent-reviewer-cr2 referenced this pull request 2026-06-26 08:09:52 +00:00

ci(secrets->kms): fix CF zone-id Infisical path (cloudflare-admin -> cloudflare-tunnel-admin) in sweep-cf-orphans #3291

hongming referenced this pull request 2026-06-26 08:14:59 +00:00

ci(secrets->kms): staging consumers fetch CP admin token + MiniMax from Infisical (complete wave B) #3294

agent-dev-a referenced this pull request 2026-06-26 11:36:28 +00:00

fix(ci): CLOUDFLARE_ACCOUNT_ID Infisical path -> /shared/cloudflare-admin per bootsecrets.go canonical #3303

agent-researcher referenced this pull request 2026-06-26 12:35:21 +00:00

fix(ci): CLOUDFLARE_ACCOUNT_ID Infisical path -> /shared/cloudflare-admin per bootsecrets.go canonical #3303

Sign in to join this conversation.

Reviewers

No Reviewers

agent-researcher

agent-reviewer-cr2

Labels

Clear labels

approved

area/ci

CI/CD pipeline issues

do-not-auto-merge

Opt out of autonomous merge-queue merging

do-not-merge

hold from auto-merge (design review in progress)

kind/infrastructure

Infrastructure-related issues

merge-queue

Ready for serialized Gitea merge queue

merge-queue-hold

Temporarily hold PR in merge queue

needs-engineer

platform/go

Go platform test issues

ready-to-build

release-blocker

Blocks the staging→main promotion / a release

release-test

security

test-label-sre

tier:high

High risk per dev-sop §SOP-6 — ceo only, 24h cooldown

tier:low

Low risk per dev-sop §SOP-6 — engineers/managers/ceo can approve

tier:medium

Medium risk per dev-sop §SOP-6 — managers/ceo can approve

triage-test

test

wip

Work in progress — do not auto-merge

No Label

Milestone

No items

No Milestone

Projects

Clear projects

No project

Assignees

Clear assignees

agent-dev-a agent-dev-b agent-pm agent-researcher agent-reviewer agent-reviewer-1 agent-reviewer-cr2 app-fe (Molecule AI · app-fe) app-lead (Molecule AI · app-lead) app-qa (Molecule AI · app-qa) claude-ceo-assistant claude-ci-reader core-be (Molecule AI · core-be) core-devops (Molecule AI · core-devops) core-fe (Molecule AI · core-fe) core-lead (Molecule AI · core-lead) core-offsec (Molecule AI · core-offsec) core-qa (Molecule AI · core-qa) core-security (Molecule AI · core-security) core-uiux (Molecule AI · core-uiux) cp-be (Molecule AI · cp-be) cp-lead (Molecule AI · cp-lead) cp-qa (Molecule AI · cp-qa) cp-security (Molecule AI · cp-security) cui (Zhanlin Cui) dev-lead (Molecule AI · dev-lead) devops-engineer documentation-specialist (Molecule AI · documentation-specialist) fullstack-engineer (Molecule AI · fullstack-engineer) godwin hongming hongming-ceo-delegated hongming-codex-laptop hongming-kimi-laptop hongming-pc2 hongming-personal infra-lead (Molecule AI · infra-lead) infra-runtime-be (Molecule AI · infra-runtime-be) infra-sre (Molecule AI · infra-sre) integration-tester (Molecule AI · integration-tester) mc-drift-bot molecule-code-reviewer plugin-dev (Molecule AI · plugin-dev) pm publish-runtime-bot pypi-publisher (Molecule AI PyPI Publisher (RFC#596)) release-manager (Molecule AI · release-manager) sdk-dev (Molecule AI · sdk-dev) sdk-lead (Molecule AI · sdk-lead) sop-drift-bot sop-tier-bot (SOP Tier-Check Bot) technical-writer (Molecule AI · technical-writer) triage-operator (Molecule AI · triage-operator)

No Assignees

3 Participants

Notifications

Subscribe

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: molecule-ai/molecule-core#3289