[dev-dull]

Summary

Closes #79. The /api/secrets routes exposed full CRUD over cluster secrets in the workloads namespace with no authentication. Build/run pods call the platform API directly (bypassing the Authelia forward-auth proxy), so any LLM-built app could read the operator's sus-git-token / sus-anthropic-api-key in plaintext and create, overwrite, or delete any secret — an app→platform privilege escalation.

Posture (confirmed with maintainer): operator-only. Pods get no secrets self-service.

Changes

• Auth gate. New require_operator dependency, applied at the /api/secrets router level so every current and future route is covered. Pods resolve to the anonymous guest identity and are now rejected with 403. No-op in single-user / no-auth deployments, where every request is the local operator by design.
• Defence in depth. A denylist of platform-owned secrets — sourced from the git-token / api-key managers that own them (so a rename can't silently un-protect them), extensible via SUS_PROTECTED_SECRETS — is never listed, read-with-values, or mutated through this API, even for an authenticated operator. This is what protects those credentials in single-user / open-proxy modes, where a pod can appear authenticated.
• Docs. Removed the pod-facing secrets API section from build-pod/CLAUDE.md.
• Tests. New landing/tests/test_secrets_auth.py: guests rejected on every verb; operator listings exclude protected secrets; protected names blocked before any K8s call. Full landing suite: 32 passed.

Not in scope (follow-ups)

• Tightening the landing ServiceAccount's secrets RBAC (overlaps with Harden build-pod isolation with primitives we already have (egress NetworkPolicy, securityContext, SA-token, secrets API) #110).
• Per-app scoped secret self-service (the rejected posture).

🤖 Generated with Claude Code

[github-actions]

Claude finished @dev-dull's task in 1m 21s —— View job

---

Review: fix(secrets): gate /api/secrets behind operator auth

• Read the diff
• Check the identity providers and proxy trust (how pods resolve)
• Check other code that reaches the same secrets
• Post the review

Overall: The core fix is solid. require_operator is applied at the router level, so any future /api/secrets route is covered too. A pod's identity does resolve to guest under ProxyHeaderProvider when trusted_proxies is set, and under LocalDatabaseProvider when there is no cookie, so it gets a 403. The denylist uses the managers' own SECRET_NAME constants, and those managers use the same SUS_WORKLOADS_NAMESPACE as this router, so the names line up. The checks run before any Kubernetes call, and in POST they run after .strip(). The tests cover both the gate and the denylist. I found no issues in the changed code itself.

1. The same credentials are still writable through /setup (inline comment on secrets.py:33-40)

• setup_router (landing/app/routes/setup.py) has no auth. Any pod can call POST /setup/git-token, /setup/api-key or /setup/repo-url.
• That lets a pod overwrite sus-git-token or sus-anthropic-api-key, the secrets this PR protects.
• It can also point the platform's catalog sync at a repo it controls.
• This is the same app→platform gap as Security: /api/secrets is unauthenticated — built apps can exfiltrate operator credentials #79, so the PR's claim that these secrets are "never mutated" only holds for /api/secrets. Gating the setup router with the same require_operator dependency is a one-line change. If you'd rather keep this PR narrow, a follow-up issue works.

2. Outdated docs (minor) – these still describe /api/secrets as available to apps or not yet authenticated:

• README.md:295 ("used by apps via the SUS Platform API")
• SUS - Platform Design.md:303 ("apps can manage credentials")
• charts/sus/templates/networkpolicy.yaml:13 (comment says authenticating Security: /api/secrets is unauthenticated — built apps can exfiltrate operator credentials #79 is still to do)

Notes:

• The chart didn't change, so I didn't run helm template.
• I couldn't run the test suite: running pytest needs approval in this environment. The PR reports 32 passing.
• As the PR says, in single-user mode or with ProxyHeaderProvider and no trusted_proxies, a pod still counts as the operator. In that case it can create, read and delete every secret except the protected ones. That matches the stated scope and the Harden build-pod isolation with primitives we already have (egress NetworkPolicy, securityContext, SA-token, secrets API) #110 follow-up.

[github-actions]

These same secrets can still be overwritten through /setup, so the denylist doesn't fully deliver "never mutated through this API".

landing/app/routes/setup.py has POST /setup/api-key, POST /setup/git-token and POST /setup/repo-url. They write sus-anthropic-api-key and sus-git-token through the managers and call clone_or_pull(). The setup_router is included in main.py:46 with no dependency, so a build/run pod that resolves to guest can still:

• replace the operator's git token or API key with its own (a write rather than a read, but still a takeover of platform credentials), and
• point SUS_GIT_REPO_URL at a repo it controls. The platform would then sync its catalog and skills from that repo, which is arguably worse than reading the token.

This is the same app→platform gap as #79, one router over. The cheapest fix fits in this PR: give the setup router the same gate, APIRouter(prefix="/setup", dependencies=[Depends(require_operator)]), at least for the POST routes. If you'd rather keep this PR narrow, please open a follow-up. Either way, the PR description's "never … mutated … even for an operator" claim only holds for /api/secrets.

Fix this →

[github-actions]

Claude finished @dev-dull's task in 28s —— View job

---

Re-review after 30ea50f

• Read the new diff (git diff origin/main...HEAD)
• Check whether the earlier review's findings were addressed
• Look for anything new in the changed code
• Post the summary

Both findings from the last review are fixed. This looks good to merge.

1. /setup is now gated. setup.py:24 applies require_operator at the router level. That covers POST /setup/{api-key,git-token,repo-url} as well as GET /setup and /setup/api/status. A pod that resolves to guest can no longer overwrite the git token or API key, or point catalog sync at its own repo. test_setup_routes_require_operator covers every one of these routes.
2. The outdated docs are fixed. README.md:295, SUS - Platform Design.md:303 and the networkpolicy.yaml header comment now describe the operator-only posture.

test_denylist_covers_all_platform_secret_names is a good addition. If a module later defines a SECRET_NAME that isn't in the denylist, the test fails. That matters because the denylist is the only protection in single-user and open-proxy modes. The test also fails if the scan finds nothing, so it can't pass vacuously.

Minor notes (no change needed):

• In multi-user mode, a guest who sees the "SUS needs configuration" alert (index.html:110) and clicks Open Setup now gets a raw 403 JSON response. Only the operator should be configuring the platform, so this is just a UX rough edge. It isn't a bug.
• SUS - Platform Design.md:231 still calls Security: /api/secrets is unauthenticated — built apps can exfiltrate operator credentials #79 "unauthenticated /api/secrets". It reads as history of the issue, so leaving it is fine.

Notes:

• The chart change is only a comment, so I didn't run helm template.
• I couldn't run pytest here because it needs approval in this environment. I reviewed the tests by reading them.