Files
ops-warden/wiki/InterHubBootstrapAccessLane.md

3.7 KiB

Inter-Hub Bootstrap Access Lane

Date: 2026-06-17

Purpose

This runbook describes how ops-warden participates in authenticated Inter-Hub bootstrap tasks, especially the ops-hub production activation lane tracked by CUST-WP-0049.

ops-warden does not store Inter-Hub API keys. Its role is to issue short-lived SSH certificates for a narrow actor so an operator or agent can reach a trusted execution host without introducing static SSH keys into the workflow.

Boundary

ops-warden owns:

  • actor registration
  • short-lived certificate issuance
  • TTL and principal policy
  • ops-ssh-wrapper usage

ops-warden does not own:

  • Inter-Hub operator key storage
  • OpenBao policy or secret paths
  • host-side /etc/ssh/auth_principals/ deployment
  • force-command wrappers
  • database migrations or Kubernetes access

Those host-side controls belong to railiance-infra or the relevant deployment repo. Long-lived secret custody belongs in OpenBao or the approved operator secret store.

Actor Pattern

Use a dedicated agt actor for Codex-assisted bootstrap work:

warden inventory add agt-codex-interhub-bootstrap \
  --type agt \
  --principal agt-interhub-bootstrap \
  --ttl 2 \
  --description "Short-lived agent access for attended Inter-Hub bootstrap execution"

Guidance:

  • Prefer a 1-2 hour TTL for attended bootstrap.
  • Keep the principal narrower than general ops access.
  • Do not reuse human adm actors for agent-assisted bootstrap runs.
  • Remove or disable the actor after the bootstrap lane is no longer needed.

Execution Shape

The intended flow is:

  1. Operator approves the production bootstrap run.
  2. ops-warden signs a short-lived cert for agt-codex-interhub-bootstrap.
  3. The target host accepts only the narrow agt-interhub-bootstrap principal.
  4. Host-side policy maps that principal to a force-command or wrapper that can run only the Inter-Hub bootstrap routine.
  5. The wrapper reads the Inter-Hub operator key from OpenBao or an attended 0600 temp file.
  6. The wrapper runs the repo-owned bootstrap command, for example make interhub-bootstrap in ops-hub.
  7. Any generated runtime key is stored back into OpenBao immediately.
  8. The wrapper prints non-secret evidence only: ids, status, timestamps, and key prefixes.

Example client-side wrapper use:

WARDEN_ACTOR=agt-codex-interhub-bootstrap \
SSH_PUBKEY="$HOME/.ssh/id_ed25519.pub" \
ops-ssh-wrapper ssh ops-bootstrap@<trusted-host> run-ops-hub-interhub-bootstrap

The exact remote command and host account are environment-specific and should be provisioned by the deployment repo.

Host-Side Requirements

Before this lane can be used in production, railiance-infra or the deployment owner should provide:

  • an auth principals entry for agt-interhub-bootstrap
  • password auth disabled for the target account
  • a force-command or restricted wrapper for the bootstrap path
  • OpenBao read access for the Inter-Hub operator key, if unattended material access is approved
  • OpenBao write access for the generated ops-hub runtime key
  • non-secret execution logging

Without those controls, use only an attended local IHUB_OPERATOR_KEY_FILE run.

Non-Secret Evidence

Safe evidence to copy into State Hub:

  • workplan id and task id
  • Inter-Hub base URL
  • hub id and slug
  • manifest id and status
  • API consumer id
  • runtime key prefix
  • widget counts
  • event id and event type

Never log:

  • full operator keys
  • full runtime API keys
  • OpenBao tokens
  • kubeconfig contents
  • raw SQL output that could include secrets
  • the-custodian/workplans/CUST-WP-0049-interhub-bootstrap-access-lane.md
  • ops-hub/docs/bootstrap-runbook.md
  • wiki/AccessManagementDirective.md
  • wiki/OpsWardenConfig.md
  • wiki/CertCommandInterface.md