# 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:

```bash
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:

```bash
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

## Related Work

- `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`