binky-control/integrations/executor-worker-secrets.md

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)
• Lane 1: nothing to do — reuse confirmed

T04 (worker MVP) can start with Lane 1 alone plus a workstation-side dry run; Lanes 2–3 gate unattended operation, not development.