binky-control/integrations/executor-worker-secrets.md
tegwick ce14c254db BINKY-WP-0004-T03: executor worker secret lanes prepared
- Lane 1 (LLM provider): reuse verified — warden catalog
  openrouter-llm-connect, policy workload-kv-read-llm-connect-provider-secrets
- Lane 2 (forgejo deploy key): new, per-repo write deploy key design,
  founder Red lane
- Lane 3 (mail-scan AppRole): executor-worker-binky-mail bound to the
  existing IMAP read policy — closes email checklist item 9's auth
  blocker on paper; provisioning founder Red lane
- No secret values anywhere; T04 can proceed on Lane 1 alone

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
2026-07-17 17:08:33 +02:00

86 lines
4 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.

# Executor Worker — 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 executor worker (DEC-2026-002: new small repo, 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
executor worker 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/executor-worker/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-executor-worker-forgejo` scoped to
that path; warden catalog entry `executor-worker-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 `executor-worker-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 `executor-worker-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
- [ ] Lane 2: forgejo deploy key (generate, register on sandbox repo, store
in OpenBao, catalog entry)
- [ ] Lane 3: AppRole `executor-worker-binky-mail` (create role, deliver
role_id/secret_id to Railiance, catalog entry)
- [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.