SEC-021/-022/-023: live credential defects found during D-137 matrix research ...

Recorded, NOT actioned (hard rule 1). Open SEC rows 16 -> 19. These surfaced
while gathering inputs for the credential matrix and are live defects
independent of any D-137 ruling.

SEC-021 dc0 custody defects. (a) changelog-20260719-dc0-deploy-stepB.md:263
records the dc0 edge REST API credential consolidated to
~/vr1-dc0-creds/opnsense-api.txt; that file exists for office1 and dc1 only --
no dc0 copy -- and creds-audit vr1-dc0 says CLEAN because it was never
manifested. A changelog asserting consolidation is not evidence it survived.
Not a lockout: the dc0 edge SSH key is present, D-112(c) SSH is the primary
path. (b) dc0 power key = maas-virsh_ed25519 on voffice1 vs dc1's declared
vr1-dc1-maas-power_ed25519{,.pub} on vcloud -- name/host/custody divergence.

SEC-022 two UNAUDITED shadow *-creds/ stores on voffice1 holding real key
material. creds-audit.sh:29-31 resolves under $HOME on the host it runs on
(vcloud) and has no ssh, so an entire parallel store is structurally
invisible. A scope gap in the control, not a one-off: D-128 puts Plane-2
execution on voffice1.

SEC-023 sprawl globs (creds-audit.sh:72-73) miss admin.pass, *.apikey, *.key,
*.pem, *_ed25519, maas-api-key.txt. Plus a PREDICTED exposure recorded before
it exists: phase-03-admin-openrc.sh:32,72 writes OS_PASSWORD into
$HOME/admin-openrc at Stage 5, home root, matching no glob.

Also reconciles the CURRENT-STATE G14 evidence cell to a measured 19 (it read
12 from 07-23) since this commit adds three of them, and re-seeds the ledger
machine block.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01HvCyrwvYTTcDYnRErfMsNf

D-137 PROPOSED: credential mint-and-consolidate pipeline -- make consolidation structural [ARCH] ...

Operator ask: a better method for minting/saving credentials, plus "a durable
rule to make sure when accounts are created there is a consolidation that
happens every time so credentials aren't misplaced or lost."

PROPOSED only -- no tooling built, no enforcement wired, no SEC-009 demotion.
Three forks are presented for ruling, one exchange each (GA-R5).

Measured diagnosis: the existing SEC-009 control CANNOT DETECT THE FAILURE
CLASS IT WAS BUILT FOR, because creds-audit is DECLARATION-based -- the
manifest IS the declaration, so an undeclared secret is structurally
invisible and a green CLEAN is not evidence nothing was missed.
- creds-audit vr1-office1 read CLEAN on 2026-07-15 while four secrets minted
  on the region VM on 2026-07-13 (site-headend-install.sh:416-455) sat
  undeclared; admin.pass surfaced only 2026-07-25 (SEC-020), 12 days later,
  and only because a task went looking.
- No --all (creds-audit.sh:25 takes one mandatory site).
- Enforcement is PROSE in exactly one place (phase-3 runbook:498), absent from
  preflight/cloud-assert/repo-lint/gauntlet -- and it did not fire at EITHER
  DC standup (dc0 3 + dc1 1 undeclared at this session's open).
- No D governs credential mint/custody generally (D-069 = Vault unseal keys,
  D-126 = per-env key isolation), so the rule lives only in the security
  ledger -- a register of exposures, which no gate can cite as authority.

Proposal: mint-and-consolidate as ONE operation (creds-mint.sh), plus the
DISCOVERY inversion (creds-audit --all/--remote against declared VM secret
locations -- the only piece that would have caught admin.pass), plus gate
wiring, plus a site-headend-install.sh amendment at the source.

The SEC-020 identity-conflation question stays SEPARATE (not batched, GA-R5)
and remains D-unassigned.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01HvCyrwvYTTcDYnRErfMsNf

SEC-020: MAAS admin-account recovery -- consolidate `admin`, mint `operator`, creds-audit CLEAN x3 ...

Operator task: recover the MAAS admin accounts and save the creds retrievably.
The task premise was FALSIFIED by measurement before any mutation: the ledger's
2026-07-25 "MAAS web-GUI login does NOT exist / never minted" was wrong. The
`admin` password was minted 2026-07-13 by site-headend-install.sh:452 and is
MEASURED working (login 204 vs 400 wrong-password control). It was merely
root-only on voffice1 and un-consolidated -- the SEC-009 miss class, not a
missing account. Scope re-ruled by the operator after that finding:
"New account + consolidate only" -- no existing password rotated.

- NEW MAAS superuser `operator` for human GUI login; password generated on
  vcloud, set via stdin (never argv -- SEC-018 discipline; changepassword has
  no --password and createadmin --password would expose it).
- `admin` password CONSOLIDATED byte-identical (sha256-verified) to
  ~/vr1-office1-creds/. NOT rotated, so the VM copy REMAINS source-of-record;
  a future rotation must update both or the VM copy becomes a stale trap.
- juju-vr1-dc0/dc1 untouched BY RULING: their SEC-018/019 API keys are
  load-bearing for the blocked Stage-5 bootstrap.
- Manifest backfill -> creds-audit CLEAN on all three sites (was RED: dc0 3 +
  dc1 1 undeclared), closing the dc0 edge-keypair queued finding named in
  vr1-dc1.manifest:18-20.
- Root cause recorded: `admin` doubles as the automation identity (19 `maas
  admin` call sites in 4 scripts), so automation never needed the password and
  nothing forced it into the folder. Proposable as the next-free D-number
  [ARCH]; NOT assigned (GA-R3 doubt-resolves-DOWN).
- Falsified ledger claim struck+corrected; machine-derived block re-seeded
  (was stale on every line: SEC 12->16, next-free D 133->137, DOCFIX 200->204).

Evidence: docs/audit/maas-admin-recovery-20260725.txt (generated, no secret
values; scanned for password bytes = 0 hits with a planted-control check).
repo-lint 0 fail; gauntlet ALL GREEN (79).

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01HvCyrwvYTTcDYnRErfMsNf