feat(openbao): secret-exists-check policy for Argus and Atlas #1039

2026-09-27T16:36:50Z

claude-bot commented

2026-09-27 16:36:50 +00:00

Lets the Paperclip agents Argus and Atlas check whether a secret exists in OpenBao without reading its value.

Policy secret-exists-check: read/list on homelab/metadata/* (whole tree, per owner): paths, versions, timestamps. No homelab/data/*, no writes.
Identity: userpass user agent-secret-check (precedent: claude-bot), tokens 1h / max 4h.
Delivery: password as one Paperclip agent secret bound to Argus and Atlas (one owner approval).

Not applied by Flux (reference HCL, like the other policies here). After merge the owner's session applies it once with the commands in the file header.

🤖 Generated with Claude Code

Lets the Paperclip agents Argus and Atlas check whether a secret exists in OpenBao without reading its value. - Policy `secret-exists-check`: `read`/`list` on `homelab/metadata/*` (whole tree, per owner): paths, versions, timestamps. No `homelab/data/*`, no writes. - Identity: userpass user `agent-secret-check` (precedent: claude-bot), tokens 1h / max 4h. - Delivery: password as one Paperclip agent secret bound to Argus and Atlas (one owner approval). Not applied by Flux (reference HCL, like the other policies here). After merge the owner's session applies it once with the commands in the file header. 🤖 Generated with [Claude Code](https://claude.com/claude-code)

claude-bot added 1 commit 2026-09-27 16:36:50 +00:00

feat(openbao): secret-exists-check policy for Argus and Atlas

ci/woodpecker/pr/ci-scripts-test Pipeline was successful

Details

ci/woodpecker/pr/ci-manifests-test Pipeline was successful

Details

ci/woodpecker/pr/pr-review Pipeline was successful

Details

9abe2ac820

Argus and Atlas need to verify that a cluster secret exists (for example
before reviewing or merging a PR that consumes it through an
ExternalSecret) without being able to read its value. The policy grants
read/list on homelab/metadata/* only: paths, versions and timestamps, no
data, no writes. Whole tree, per owner decision.

Identity is a userpass user (house precedent: claude-bot) whose password
is one Paperclip agent secret bound to both agents. Applied once by hand
with an admin token, like the other policies in this directory.

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

k.renner merged commit bd03b61eb4 into master

2026-09-27 16:37:25 +00:00

k.renner referenced this issue from a commit

2026-09-27 16:37:27 +00:00

Merge pull request 'feat(openbao): secret-exists-check policy for Argus and Atlas' (#1039) from feat/openbao-secret-exists-check into master

review-bot reviewed

2026-09-27 16:39:47 +00:00

review-bot left a comment

🤖 Automated review — model CLI default (complexity: complex), commit 9abe2ac8202f5a5ad8e6db728251787151cd388f.

Advisory review by the review-bot pipeline. It never approves; a human merges. Push new commits to get a fresh review.

Summary

Adds kubernetes/infrastructure/openbao/policies/secret-exists-check.hcl, a reference OpenBao ACL policy (not applied by Flux, like its siblings) granting read/list on homelab/metadata/* only — no homelab/data/*, no writes/deletes. Intended for a new userpass identity (agent-secret-check) whose password is delivered to the Paperclip agents "Argus" and "Atlas" as an agent secret. The file is well-scoped and follows the established pattern of the other policy files in this directory (eso-read.hcl, rotator-review-bot.hcl). No blocking issues found.

🟡 Suggestions

"Bound to Argus and Atlas" may not provide real isolation. The PR body frames this as a scoped grant to two specific agents via "one Paperclip agent secret bound to Argus and Atlas." But docs/superpowers/specs/2026-09-25-paperclip-design.md ("Known trade-off of B") documents that under the current server-local execution model, every Paperclip agent shares the same pod filesystem and can read any other agent's secrets from disk — the doc's own guardrail is "no bot may hold a credential we would not tolerate any other bot using." Given that, any agent running in the pod can plausibly read this password too, not just Argus/Atlas. Worth either acknowledging that in the header comment (so a future reader doesn't assume real isolation from the "bound to" framing) or treating the grant as effectively pod-wide. Low actual risk here since the policy only exposes metadata (paths/versions/timestamps), never secret values.
homelab/metadata/* is tree-wide across all owners, not per-owner. The header comment says "whole tree, per owner," but the path rule (kubernetes/infrastructure/openbao/policies/secret-exists-check.hcl:25-27) grants list/read across the entire homelab/metadata/* tree, so the identity can enumerate every app/owner's secret paths and version history, not just the paths belonging to whichever owner is checking. This is still strictly narrower than eso-read.hcl (which grants actual data reads tree-wide), so it's not a new precedent, but if per-owner scoping was intended, a path like homelab/metadata/<owner>/* would match the stated intent more closely.

Tests

No tests exist for the other .hcl policy files in this directory either (they're manually-applied reference files, per their own header comments), so the absence of tests here is consistent with repo convention. The file does include a manual verification recipe in its header (bao kv metadata get succeeds, bao kv get is denied), which is the appropriate substitute for this class of change.

Recommendation

Looks reasonable — no blocking issues; comments above are optional.

🤖 **Automated review** — model `CLI default` (complexity: complex), commit `9abe2ac8202f5a5ad8e6db728251787151cd388f`. > Advisory review by the `review-bot` pipeline. It never approves; a human merges. Push new commits to get a fresh review. --- ## Summary Adds `kubernetes/infrastructure/openbao/policies/secret-exists-check.hcl`, a reference OpenBao ACL policy (not applied by Flux, like its siblings) granting `read`/`list` on `homelab/metadata/*` only — no `homelab/data/*`, no writes/deletes. Intended for a new userpass identity (`agent-secret-check`) whose password is delivered to the Paperclip agents "Argus" and "Atlas" as an agent secret. The file is well-scoped and follows the established pattern of the other policy files in this directory (`eso-read.hcl`, `rotator-review-bot.hcl`). No blocking issues found. ## 🟡 Suggestions - **"Bound to Argus and Atlas" may not provide real isolation.** The PR body frames this as a scoped grant to two specific agents via "one Paperclip agent secret bound to Argus and Atlas." But `docs/superpowers/specs/2026-09-25-paperclip-design.md` ("Known trade-off of B") documents that under the current server-local execution model, every Paperclip agent shares the same pod filesystem and can read any other agent's secrets from disk — the doc's own guardrail is "no bot may hold a credential we would not tolerate any other bot using." Given that, any agent running in the pod can plausibly read this password too, not just Argus/Atlas. Worth either acknowledging that in the header comment (so a future reader doesn't assume real isolation from the "bound to" framing) or treating the grant as effectively pod-wide. Low actual risk here since the policy only exposes metadata (paths/versions/timestamps), never secret values. - **`homelab/metadata/*` is tree-wide across all owners, not per-owner.** The header comment says "whole tree, per owner," but the path rule (`kubernetes/infrastructure/openbao/policies/secret-exists-check.hcl:25-27`) grants list/read across the entire `homelab/metadata/*` tree, so the identity can enumerate every app/owner's secret paths and version history, not just the paths belonging to whichever owner is checking. This is still strictly narrower than `eso-read.hcl` (which grants actual data reads tree-wide), so it's not a new precedent, but if per-owner scoping was intended, a path like `homelab/metadata/<owner>/*` would match the stated intent more closely. ## Tests No tests exist for the other `.hcl` policy files in this directory either (they're manually-applied reference files, per their own header comments), so the absence of tests here is consistent with repo convention. The file does include a manual verification recipe in its header (`bao kv metadata get` succeeds, `bao kv get` is denied), which is the appropriate substitute for this class of change. ## Recommendation Looks reasonable — no blocking issues; comments above are optional.

Sign in to join this conversation.

2 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: konairius/homelab#1039