# creds-matrix-notes.md -- `notes-ref` targets for creds-matrix.tsv (D-137) The `notes-ref` column of `creds-matrix.tsv` points here. Free text lives HERE and never in the TSV, so the TSV stays logical-keys-only (SEC-004) and greppable. Added by the 12-column amendment 2026-07-26 (`docs/D-137-implementation-plan.md`). **Parse contract.** One `## ` heading per note; the body is every line until the next heading. `scripts/creds-matrix.py --render` emits a note as the manifest comment above the rows that reference it -- this is how D-137 ruling 2's "prose must not be dropped" obligation is met for per-row governance text. **No secret values, no paths, no hostnames** -- the same discipline as the TSV. Where a note must refer to a location it names the role token and the register row that holds the detail (`docs/security-ledger.md` remains the custody/exposure register of record). --- ## n-maas-region-admin The MAAS region `admin` superuser. Password 28 characters, alphanumeric, NO trailing newline -- that format spec is the verify-by-format basis; never verify by printing. The REGION copy is source-of-record and the jumphost copy is a byte-identical working copy (sha256-verified 2026-07-25). SEC-020 ruling: `admin`'s password was deliberately NOT rotated, so **any future rotation MUST update both copies in one operation or the region copy becomes a stale trap**. This identity is also the automation identity, which is why it carries both a `human` and a `service` row -- see `n-maas-cli-profile`. That is the ruling-5 violation D-137 exists to make machine-detectable, not a data-entry error. ## n-maas-admin-apikey Deliberately NOT consolidated (SEC-020(i)): trivially regenerable, and a second copy is pure added surface. `not-consolidated-ruled` records that this is a settled decision, so `--remote` must not report it as an undeclared find. ## n-maas-cli-profile The installer logs the CLI in as profile `admin`; 19 `maas admin ...` call sites across 4 scripts hardcode that profile (SEC-020(b)). ROOT CAUSE of the SEC-020 miss: automation only ever needed the API key, so nobody ever needed the password, so nothing forced it into the folder. Remediation is the `operator`/`admin` split begun 2026-07-25 -- migrate those call sites to a service identity, which is what clears the ruling-5 FAIL. ## n-maas-region-operator Minted 2026-07-25 for HUMAN GUI login so a person no longer authenticates as the service identity. 32-char base64, generated on the jumphost, set via **stdin -- never argv** (`createadmin --password` would expose it in argv, the shape the installer uses). The first human-only MAAS identity. ## n-region-infra-carveout Region infrastructure, ruled OUT of the consolidation task's scope (SEC-020(i)). Present at a declared location by decision, not by oversight. ## n-rack-enroll Side effect of `maas init region+rack`; consumed by each DC rack at enrollment via a 0600 copy. Mint and consume are different stages -- minted at region standup, consumed at each DC standup. ## n-no-mint-command **Research FINDING 1 -- reproducibility debt.** `ssh-keygen` returns ZERO hits repo-wide; there is likewise no `mkpasswd`, `htpasswd`, `pwgen`, `uuidgen`, nor any Terraform `random_password`/`tls_private_key`. This credential's only provenance record is a manifest comment, so **it is not reproducible**: if the jumphost is rebuilt, no repo artifact states how to recreate it. That is a Roosevelt-transfer defect, not merely hygiene. `mint-ref=operator-terminal` rows are the debt to convert, and must be admitted by the parser rather than treated as errors. ## n-edge-api OPNsense REST API key+secret, minted ON the edge via the vendor model (D-113(a2)) into a 0600 temp file that is then wiped, and retrieved to the jumphost creds folder by the bootstrap driver. ## n-third-party Operator-supplied from a third-party control server. Correctly has NO repo mint command -- this is the one FINDING 1 row that is not a defect. ## n-netbox-upstream Minted on the upstream NetBox apex. SEC-006 records this credential as BURNED; the rotation obligation stands at v1 close. ## n-netbox-sandbox **The founding SEC-009 miss.** Minted on the NetBox VM and never pulled into the creds folder; it went unnoticed until the fidelity re-check needed it. That case is why `creds-audit` exists at all, and why the source-of-record vs consolidated distinction is modelled: a VM-minted secret has no forcing function to reach the folder. ## n-netbox-vm-secrets Held on the NetBox VM, outside the jumphost creds folder. `netbox-secret-key` was rotated off netbox-docker's PUBLIC default. The admin password is a human GUI login and is a separate identity from the service SECRET_KEY -- do not merge these ids. ## n-tofu-apikey Office1 MAAS API key consumed by OpenTofu as `TF_VAR_maas_api_key`. ## n-tfstate-plaintext DOCFIX-175: the same API key reaches `terraform.tfstate` in PLAINTEXT. A secret-at-rest location with no mint of its own -- it exists only as a second copy, which is exactly what the (credential, location) row shape is for. Any rotation of `n-tofu-apikey` must account for this copy. ## n-office1-env Environment file carrying the edge root-password hash and an SSH key path. One of the three files whose loose, 0664 placement in the home directory WAS SEC-009. ## n-readme NOT a credential -- the human index of the creds folder, declared in the manifest so the folder's undeclared-file check does not fire on it. `principal` is `-` deliberately; the ruling-5 invariant must skip rows with no principal rather than fault them. ## n-edge-key Edge service SSH keypair for the D-112(c) console bootstrap. The runbook describes the bootstrap step but does NOT contain the key generation itself -- see `n-no-mint-command`. ## n-dc0-edge-api-absent **SEC-021, tier-1 detectable.** dc1 declares an edge API credential and dc0 does not, so this expected row has no manifest row to satisfy it. This is an EXPECTED-BUT-ABSENT failure, not a matrix error: do not delete the row to make the checker green. ## n-dc0-power-key-divergence **SEC-021, per-DC asymmetry.** dc1's power key is consolidated on the jumphost under a DC-qualified name; dc0's equivalent exists under a DIFFERENT name and on a DIFFERENT host-role (the headend shadow store, SEC-022). Both the name and the location diverge from the per-DC pattern, so the expected jumphost rows fail EXPECTED-BUT-ABSENT while the divergent copy shows up at a declared remote location. ## n-snap-key-fragility The private half is installed into the region MAAS snap so MAAS's own power operations can dial the rack. **The snap path is per-revision and may not survive a snap refresh -- it must be re-asserted after any refresh** (a standing DC-standup item). Per-DC isolation is mandatory here: NEVER a cross-DC power key (SEC-012 dc0, SEC-016 dc1). ## n-dc1-power-key Dedicated dc1 MAAS->libvirt power key, minted under the SEC-016 ruling "Mint a dedicated dc1 power key" (per-DC isolation). Roosevelt analog: per-DC IPMI/BMC credentials. ## n-dc-maas-apikey Per-DC MAAS admin API key backing the Juju cloud credential. Generated FROM the jumphost so it never persisted on the region -- which is why its provenance is local rather than a VM path. Verified by FORMAT ONLY (parts=3, 70 chars); never printed, echoed, or placed in argv. GRANT is admin-scoped MAAS API. The owning MAAS superuser's password is random and unstored by ruling -- see `n-juju-user-nopassword`. ## n-juju-cred-store A runtime copy lives in the Juju client credential store on the HEADEND, a consequence of running the Juju client there per D-128. The jumphost file stays canonical. Recorded off-manifest in the manifests today (SEC-018/-019); this row is what makes it visible to the checker instead. ## n-juju-user-nopassword `createadmin` is invoked with NO `--password`, so the value is stored NOWHERE. Kept random and unstored BY RULING (2026-07-25): the API key is what is load-bearing, and the `operator` identity removes any need to log in as this user. `filename` is `-` because there is no host artifact -- existence checks must skip such rows rather than fail them. ## n-headend-shadow-store **SEC-022 -- a scope gap in the control itself, not a one-off miss.** An entire parallel `*-creds/` store exists on the headend holding real key material. `creds-audit.sh:29-31` resolves the folder against `$HOME` on whatever host it runs on, and the script contains no ssh/scp at all, so these stores are structurally invisible to every check that exists today. The D-128 operating model puts Plane-2 execution on the headend, so headend-resident credentials are EXPECTED to keep appearing -- this is why ruling 3's declared-locations list must include the headend, and why adding a location row is DoD for any new mint site. ## n-outside-convention **Research FINDING 2.** A credential directory outside the SEC-009 `*-creds/` convention and outside `creds-audit` entirely -- the audit checks the per-site folders plus a loose FILE glob in the home directory, and never inspects these DIRECTORIES. Named in CLAUDE.md as a secret location, so it is KNOWN; it is simply outside the control. Materially extends SEC-023. The Vault directory holds the cloud's entire root of trust and its mint is an irreversible one-shot. ## n-overlay-in-clone Contains base64 CA cert/key blobs PLUS the issuing-CA passphrase in PLAINTEXT, written **inside the repo clone** and gitignored. Given SEC-004 (this repo is currently PUBLIC), that gitignore is the only thing standing between a CA private key and publication. ## n-tenant-dir Per-tenant credential directory outside the `*-creds/` convention (research FINDING 2). Hard tenant isolation applies: D-069 keeps custody off-repo, and D-137 ruling 3 bounds `--remote` to declared locations precisely so no tenant surface is ever walked. The runbook `tenant-onboarding-v2-DRAFT.md` documents the SAME credential set as the onboard script -- two creation locations, ONE set; do not double-count them into extra rows. ## n-charm-minted Charm-minted at bundle apply with no repo mint site, then MATERIALIZED to a file by the operator. In matrix scope per the operator-ruled materialization test (in-matrix if a credential is ever written to a file, presented by a human, or consumed out-of-band, regardless of who generated it) -- a generation-based test would have missed it entirely. ## n-predicted-openrc **PREDICTED, not present (SEC-023).** The script that writes it runs at a stage this deployment has not reached, so the checker must report this row as not-yet-expected via an explicit skip with an `[ok]`, never as a silent pass. Both readings of the acceptance test apply: this row exercises the not-yet-expected path, and the harness separately proves the widened sprawl glob CATCHES the file once it appears. ## n-cloud-only Lives in the cloud or on a unit rather than in a host file, but is consumed out-of-band (captured by an operator command at a documented step), so the materialization test puts it in scope. `filename` may be `-`; existence checks skip such rows. ## n-ephemeral-unit Written to a 0600 temp file ON the unit during a stage step. In scope because it is written to a file, but it is short-lived by design -- absence outside its step is normal, so this row must never drive an existence failure. --- ## Checker behaviour worth knowing before you "fix" it **S5 compares `mint-stage` and `mint-ref` as part of the per-DC shape, deliberately.** Today both DCs agree on both, so it does not fire on them. A future DC that legitimately mints the same credential at a DIFFERENT stage -- one standing up after Stage 5, say -- would trip S5 on a non-defect. That strictness is INTENDED: a per-DC credential appearing at a different stage or from a different mint site is exactly the drift the register exists to surface, and it should be argued about rather than absorbed. If a future DC makes it genuinely wrong, narrow it with a recorded reason -- do not silently drop the two fields from the comparison. **S3 is a partial gate on ruling 2, not a full one.** It compares parsed row fields for rows present on both sides; it does not compare manifest header prose, and `--render` emits only the consolidated jumphost rows. Byte-equality becomes enforceable once the manifests are actually replaced by rendered output, which is operator-gated because it changes what `creds-audit` demands at three sites. ## n-colocated-nonsecret NOT a credential -- a config or known-hosts artifact that happens to sit in a declared credential location. Declared so the undeclared-file check stays meaningful instead of crying wolf on every config file next to a key. `principal` is `-`, so ruling 5 skips it. --- ## Deliberate EXCLUSIONS (recorded so the decision is not silent) These credentials appear in the research capture but are NOT matrix rows, because they fail the materialization test -- never written to a file, never presented to a human, never consumed out-of-band: - Per-service DB / RabbitMQ / Ceph keyring credentials -- charm relation data (the capture confirms 56 apps, zero hardcoded secret options in the bundle). - Vault-issued per-service TLS certificates -- they cascade from the charm-pki-local root; the verify script checks them, nothing mints them. - The charm-pki-local root CA itself -- created inside Vault and never materialized. - The short-lived (10-minute TTL) child Vault token and the charm authorization token -- printed once, deliberately so the root token never reaches juju logs. - CAPI/CAPO per-cluster CAs and bootstrap tokens, and per-cluster trustee users/trusts -- in-cluster Kubernetes Secrets and cloud-side objects, minted at every cluster create. - Throwaway acceptance-run credentials -- created and deleted within the same run. - Tenant end-user passwords and client-minted CI application credentials -- these live on CLIENT infrastructure, outside this cloud's custody entirely. If any of these later becomes materialized to a file, it acquires a row at that moment -- adding one is DoD for the change that materializes it.