binky-control/integrations/executor-worker-secrets.md
tegwick 11bba92b84 docs: mark agent-harness Red-lane secrets Lanes 2–3 provisioned
Forgejo sandbox deploy key and mail AppRole delivered to railiance01;
checkboxes closed with host path and catalog ids (no secret values).
2026-07-17 23:57:56 +02:00

96 lines
4.7 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

# Agent Harness — OpenBao Secret Lanes (BINKY-WP-0004-T03)
> Status: prepared 2026-07-17. Catalog metadata and provisioning steps only —
> **no secret values appear here or anywhere in git/hub/chat**. All new
> provisioning is founder Red lane per AutonomyPolicy.md.
The agent harness (DEC-2026-002 resolved: single shared runtime repo `agent-harness`, deployed on Railiance)
needs three credential lanes. One exists and is reusable; two need
provisioning.
## Lane 1 — LLM provider key: REUSE (verified)
Warden catalog `openrouter-llm-connect` (active, resolvable, reviewed
2026-07-02):
- Path: `platform/workloads/activity-core/llm-connect/llm-connect-provider-secrets`
- Field: `OPENROUTER_API_KEY`
- Auth: any token carrying policy `workload-kv-read-llm-connect-provider-secrets`
- Policy gate: `flex-auth check secret.read:llm-connect` (advisory today)
**Verdict: reuse.** The key is scoped to "llm-connect in activity-core"; the
agent harness is the consumer that scoping anticipated (it executes tasks
activity-core emits, via llm-connect adapters). No new secret needed. If the
worker later gets its own workload identity, bind that identity to the same
policy — same secret, separate auth principal — rather than duplicating the
key.
## Lane 2 — Forgejo deploy key: NEW (Red lane)
No warden catalog entry exists (checked 2026-07-17; nearest match falls
through to `key-cape-oidc-login`). The worker must push commits to target
repos on forgejo (railiance01:30022), starting with a sandbox repo (T04),
later binky-control (T06).
Proposed provisioning (founder Red lane, ~10 min):
1. Generate an ed25519 keypair on Railiance (worker host), private key never
leaves the host; store a copy under OpenBao
`platform/workloads/agent-harness/forgejo-deploy-key`
(fields: `SSH_PRIVATE_KEY`, `SSH_PUBLIC_KEY`).
2. In forgejo, add the public key as a **per-repo deploy key with write
access** — sandbox repo only at first; add binky-control at T06 cutover.
Per-repo deploy keys beat a machine-user account here: blast radius is
exactly the repo list.
3. New OpenBao policy `workload-kv-read-agent-harness-forgejo` scoped to
that path; warden catalog entry `agent-harness-forgejo-deploy` (owner:
railiance-platform, risk: high).
## Lane 3 — Non-interactive AppRole for company-email scan: NEW (Red lane)
Blocker being closed: the existing OIDC role
`binky-company-email-imap-workload-kv-read` is browser-interactive with a
15-minute TTL — unusable for recurring scans (email-integration checklist
item 9, `integrations/company-email-openbao.md`).
Proposed provisioning (founder Red lane, ~10 min):
1. Enable/confirm AppRole auth on the OpenBao instance (`bao auth list`;
enable at path `approle` if absent).
2. Create role `agent-harness-binky-mail` bound to the **existing** policy
`workload-kv-read-binky-company-email-imap` (no policy change needed):
`token_ttl=15m`, `token_max_ttl=30m`, `secret_id_ttl=0` (or rotate
quarterly), `token_num_uses` bounded.
3. Deliver `role_id` + `secret_id` to the worker host via the
secrets-engine delivery mechanism (files `0600` on Railiance, outside any
repo). The worker logs in per run:
`bao write auth/approle/login role_id=… secret_id=…` → short-lived token
`bao kv get -field=IMAP_USERNAME|IMAP_PASSWORD tenants/binky/company-email/imap`.
4. Warden catalog entry `agent-harness-binky-mail-approle` (owner:
railiance-platform, risk: high) so the lane is discoverable and audited.
Scan invocation stays exactly the manual pattern (read-only email-connect,
values only ever in process env):
config `integrations/mailbox-binky-company.yml`, reports to
`mailmeta/reports/`.
## Founder Red-lane summary
- [x] Lane 2: forgejo deploy key (generate, register on sandbox repo, store
in OpenBao, catalog entry) — **done 2026-07-17** on railiance01;
write deploy key on `coulomb/executor-sandbox`; catalog
`agent-harness-forgejo-deploy`. Add `binky-control` deploy key at
cutover only.
- [x] Lane 3: AppRole `agent-harness-binky-mail` (create role, deliver
role_id/secret_id to Railiance, catalog entry) — **done 2026-07-17**;
host dir `~/.local/agent-harness/approle-binky-mail`; catalog
`agent-harness-binky-mail-approle`. Positive IMAP field presence +
negative sibling-path deny verified (no values logged).
- [x] Lane 1: nothing to do — reuse confirmed
T04 (worker MVP) can start with Lane 1 alone plus a workstation-side dry
run; Lanes 23 gate unattended operation, not development.
Host env helper (railiance01): `source ~/.local/agent-harness/env` sets
`BAO_ADDR`, `EXECUTOR_APPROLE_DIR`, and `PATH` for `bao`. Git SSH alias:
`forgejo-agent-harness` → forgejo.coulomb.social:30022 with the deploy key.