chart: cookie-secret lookup-generate is un-applyable by the fleet CD deployer (secrets RBAC); default SSM paths derive from fullname, not release name #12

New issue

Closed

opened 2026-07-08 08:40:06 +00:00 by coilyco-ops · 2 comments

coilyco-ops commented

2026-07-08 08:40:06 +00:00

Member

Found while fixing coilyco-bridge/deploy#71 (both ward-mcp public routes 500ing on every gated request).

Two chart problems:

#11's lookup-generate cookie-secret breaks CD. chart/templates/route.yaml at 5659d5f renders the oauth2-proxy cookie-secret as a chart-owned kind: Secret, seeded via lookup. The fleet CD deployer SA has no secrets verbs in the MCP namespaces by design (deploy#65, infrastructure forgejo-runner-deploy.yml keeps them out of the cluster-wide deployer-apps ClusterRole) - so the lookup 403s at render and the Secret apply would 403 anyway. Every helm upgrade from the deploy runner fails; deploy pinned its rollouts to d6b2fae (the last ExternalSecret-cookie revision) to route around it (deploy#74 tracks the unpin). A CD-compatible cookie autogen must not require the installer to read or write Secrets - or the auth overlay moves out of the chart entirely (deploy#68).
Default oauth2-proxy SSM paths derive from the Helm fullname, not the release name. route.auth.clientSecretRef/cookieSecretRef default to /<fullname>/oauth2-proxy/... where fullname is <release>-ward-mcp (e.g. /skillsmp-ward-mcp/oauth2-proxy/cookie-secret), while values.yaml's comment says the defaults 'derive from the release name'. Deploy-side docs repeated that and the operator minted params at the release-name paths, so the gate ExternalSecrets never synced, oauth2-proxy never started, and Traefik ForwardAuth returned empty 500s for every gated request - the deploy#71 outage. Fix the comment or the derivation, and consider defaulting clientSecretRef to the shared /authelia/oidc-claude-client-secret (the deploy#69 endpoint).

Found while fixing coilyco-bridge/deploy#71 (both ward-mcp public routes 500ing on every gated request). Two chart problems: 1. **#11's lookup-generate cookie-secret breaks CD.** `chart/templates/route.yaml` at 5659d5f renders the oauth2-proxy cookie-secret as a chart-owned `kind: Secret`, seeded via `lookup`. The fleet CD deployer SA has no `secrets` verbs in the MCP namespaces by design (deploy#65, infrastructure forgejo-runner-deploy.yml keeps them out of the cluster-wide deployer-apps ClusterRole) - so the `lookup` 403s at render and the Secret apply would 403 anyway. Every `helm upgrade` from the deploy runner fails; deploy pinned its rollouts to d6b2fae (the last ExternalSecret-cookie revision) to route around it (deploy#74 tracks the unpin). A CD-compatible cookie autogen must not require the installer to read or write Secrets - or the auth overlay moves out of the chart entirely (deploy#68). 2. **Default oauth2-proxy SSM paths derive from the Helm fullname, not the release name.** `route.auth.clientSecretRef`/`cookieSecretRef` default to `/<fullname>/oauth2-proxy/...` where fullname is `<release>-ward-mcp` (e.g. `/skillsmp-ward-mcp/oauth2-proxy/cookie-secret`), while values.yaml's comment says the defaults 'derive from the release name'. Deploy-side docs repeated that and the operator minted params at the release-name paths, so the gate ExternalSecrets never synced, oauth2-proxy never started, and Traefik ForwardAuth returned empty 500s for every gated request - the deploy#71 outage. Fix the comment or the derivation, and consider defaulting clientSecretRef to the shared `/authelia/oidc-claude-client-secret` (the deploy#69 endpoint).

coilyco-ops added the

headless

label

2026-07-08 16:35:09 +00:00

coilyco-ops commented

2026-07-08 17:08:14 +00:00

Author

Member

🔒 Reserved by ward agent --harness codex — container engineer-codex-ward-mcp-12 on host kais-macbook-pro-2.local is carrying this issue (reserved 2026-07-08T17:08:11Z). Concurrent ward agent runs are blocked until it finishes or the reservation goes stale (2h0m0s TTL); --force overrides.

Do not comment on or edit this issue to steer the run while it is reserved. The engineer seeded the body once at launch and never re-reads it, so a comment or edit reaches only human readers, never the running engineer. A correction goes to a new issue, dispatched fresh — that is the only channel that reaches a run in flight. Where the forge supports it, ward locks this conversation to make that a road-block rather than a convention (ward#494).

run seed context — what this run is carrying (ward#609)

Resolved: coilyco-flight-deck/ward-mcp#12 · branch issue-12 · harness codex · workflow direct-main
Run: engineer-codex-ward-mcp-12 · ward v0.451.0 · dispatched 2026-07-08T17:08:11Z
Comment thread: 0 included in the pre-flight read, 0 stripped (ward's own automated comments).

Issue body as seeded:

Found while fixing coilyco-bridge/deploy#71 (both ward-mcp public routes 500ing on every gated request).

Two chart problems:

1. **#11's lookup-generate cookie-secret breaks CD.** `chart/templates/route.yaml` at 5659d5f renders the oauth2-proxy cookie-secret as a chart-owned `kind: Secret`, seeded via `lookup`. The fleet CD deployer SA has no `secrets` verbs in the MCP namespaces by design (deploy#65, infrastructure forgejo-runner-deploy.yml keeps them out of the cluster-wide deployer-apps ClusterRole) - so the `lookup` 403s at render and the Secret apply would 403 anyway. Every `helm upgrade` from the deploy runner fails; deploy pinned its rollouts to d6b2fae (the last ExternalSecret-cookie revision) to route around it (deploy#74 tracks the unpin). A CD-compatible cookie autogen must not require the installer to read or write Secrets - or the auth overlay moves out of the chart entirely (deploy#68).

2. **Default oauth2-proxy SSM paths derive from the Helm fullname, not the release name.** `route.auth.clientSecretRef`/`cookieSecretRef` default to `/<fullname>/oauth2-proxy/...` where fullname is `<release>-ward-mcp` (e.g. `/skillsmp-ward-mcp/oauth2-proxy/cookie-secret`), while values.yaml's comment says the defaults 'derive from the release name'. Deploy-side docs repeated that and the operator minted params at the release-name paths, so the gate ExternalSecrets never synced, oauth2-proxy never started, and Traefik ForwardAuth returned empty 500s for every gated request - the deploy#71 outage. Fix the comment or the derivation, and consider defaulting clientSecretRef to the shared `/authelia/oidc-claude-client-secret` (the deploy#69 endpoint).

Static container doctrine and seed boilerplate are identical every run and omitted here (they ride ward v0.451.0).

— Codex, via ward agent

🔒 Reserved by `ward agent --harness codex` — container `engineer-codex-ward-mcp-12` on host `kais-macbook-pro-2.local` is carrying this issue (reserved 2026-07-08T17:08:11Z). Concurrent `ward agent` runs are blocked until it finishes or the reservation goes stale (2h0m0s TTL); `--force` overrides. **Do not comment on or edit this issue to steer the run while it is reserved.** The engineer seeded the body once at launch and never re-reads it, so a comment or edit reaches only human readers, never the running engineer. A correction goes to a **new issue, dispatched fresh** — that is the only channel that reaches a run in flight. Where the forge supports it, ward locks this conversation to make that a road-block rather than a convention (ward#494). <details><summary>run seed context — what this run is carrying (ward#609)</summary> - **Resolved:** `coilyco-flight-deck/ward-mcp#12` · branch `issue-12` · harness `codex` · workflow `direct-main` - **Run:** `engineer-codex-ward-mcp-12` · ward `v0.451.0` · dispatched `2026-07-08T17:08:11Z` - **Comment thread:** 0 included in the pre-flight read, 0 stripped (ward's own automated comments). **Issue body as seeded:** ``` Found while fixing coilyco-bridge/deploy#71 (both ward-mcp public routes 500ing on every gated request). Two chart problems: 1. **#11's lookup-generate cookie-secret breaks CD.** `chart/templates/route.yaml` at 5659d5f renders the oauth2-proxy cookie-secret as a chart-owned `kind: Secret`, seeded via `lookup`. The fleet CD deployer SA has no `secrets` verbs in the MCP namespaces by design (deploy#65, infrastructure forgejo-runner-deploy.yml keeps them out of the cluster-wide deployer-apps ClusterRole) - so the `lookup` 403s at render and the Secret apply would 403 anyway. Every `helm upgrade` from the deploy runner fails; deploy pinned its rollouts to d6b2fae (the last ExternalSecret-cookie revision) to route around it (deploy#74 tracks the unpin). A CD-compatible cookie autogen must not require the installer to read or write Secrets - or the auth overlay moves out of the chart entirely (deploy#68). 2. **Default oauth2-proxy SSM paths derive from the Helm fullname, not the release name.** `route.auth.clientSecretRef`/`cookieSecretRef` default to `/<fullname>/oauth2-proxy/...` where fullname is `<release>-ward-mcp` (e.g. `/skillsmp-ward-mcp/oauth2-proxy/cookie-secret`), while values.yaml's comment says the defaults 'derive from the release name'. Deploy-side docs repeated that and the operator minted params at the release-name paths, so the gate ExternalSecrets never synced, oauth2-proxy never started, and Traefik ForwardAuth returned empty 500s for every gated request - the deploy#71 outage. Fix the comment or the derivation, and consider defaulting clientSecretRef to the shared `/authelia/oidc-claude-client-secret` (the deploy#69 endpoint). ``` Static container doctrine and seed boilerplate are identical every run and omitted here (they ride ward v0.451.0). </details>  — Codex, via `ward agent`

coilyco-ops referenced this issue from a commit

2026-07-08 17:13:48 +00:00

fix(chart): generate oauth cookie secret in-cluster

coilyco-ops closed this issue

2026-07-08 17:13:48 +00:00

coilyco-ops commented

2026-07-08 17:14:13 +00:00

Author

Member

WARD-OUTCOME: done - cookie-secret now comes from an ESO password generator and the auth client-secret defaults to the shared Authelia path.

The chart stopped fighting me once I replaced the Helm lookup Secret with an ESO-backed generator/ExternalSecret pair. The only surprise was that the review panel was advisory-only because no second model family was available, so the change got an extra docs pass but not a real gate.

PR-BODY-NOTE: ADVISORY-ONLY REVIEW: no heterogeneous reviewer family was available besides the worker (codex), so the adversarial panel could not run and did NOT gate this diff. Dropped: opencode (unavailable: opencode not on PATH); codex (worker's own family - never reviews its own diff). A human should review this change with the extra scrutiny an unrun panel would have applied.

WARD-OUTCOME: done - cookie-secret now comes from an ESO password generator and the auth client-secret defaults to the shared Authelia path. The chart stopped fighting me once I replaced the Helm lookup Secret with an ESO-backed generator/ExternalSecret pair. The only surprise was that the review panel was advisory-only because no second model family was available, so the change got an extra docs pass but not a real gate. PR-BODY-NOTE: ADVISORY-ONLY REVIEW: no heterogeneous reviewer family was available besides the worker (codex), so the adversarial panel could not run and did NOT gate this diff. Dropped: opencode (unavailable: opencode not on PATH); codex (worker's own family - never reviews its own diff). A human should review this change with the extra scrutiny an unrun panel would have applied.