Credential creation-point inventory -- 2026-07-25

Read-only research capture for the D-137 credential-matrix design. No credential file was opened; every row below is a file:line reference to CODE or RUNBOOK PROSE that mints, materializes, or uploads credential material.

Classification used: MINT (new secret material comes into existence), MATERIALIZE (an existing secret is fetched/copied/written somewhere new), UPLOAD (public key registered -- no secret created). Only MINT rows are creation points; the other two classes were checked and excluded deliberately.

Operator-ruled scope for the matrix (this session): the 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.

Counts

FINDING 1 -- twelve declared secrets have NO mint command anywhere

This is the most consequential result and it qualifies the "creation points are already known" premise: for twelve standing credentials, they are not.

grep -rnI "ssh-keygen" . returns ZERO hits repo-wide (searched everything except .git/.terraform/tfstate/tfplan, including tests/, docs/archive/, clientdocs/, .claude/). There is likewise no mkpasswd, htpasswd, password_hash, pwgen, uuidgen, nor any Terraform random_password / tls_private_key. Yet the manifests declare:

Six SSH keypairs and the OPNsense root password/hash are pure operator-terminal mints whose only record is a manifest comment. Consequence: they are not reproducible. If the jumphost is rebuilt, no repo artifact states how to recreate them -- which is a Roosevelt-transfer defect, not merely a hygiene one. The tailscale key is genuinely third-party and correctly has no repo mint.

FINDING 2 -- credential directories OUTSIDE the *-creds/ convention

SEC-009 says all site secrets live in ~/<site>-creds/. The inventory shows at least three other jumphost directories holding credential material, none of which creds-audit covers (it checks ~/<site>-creds/ folders plus a loose-FILE sprawl glob in $HOME -- it never inspects these DIRECTORIES):

• ~/vault-init/init.txt -- Vault 5 unseal shares + root token, the cloud's entire root of trust (runbooks/phase-02-vault-bringup.md:71, irreversible one-shot).
• ~/octavia-pki/ -- 8 artifacts: 2 CA passphrases, 2 CA private keys, 2 CA certs, the controller key, the signed bundle (runbooks/phase-01-bundle-deploy.md:299-410).
• ~/tenant-<client>/ -- per-tenant domain-admin / cluster / svc passwords, an application credential, and a Nova private key (scripts/tenant-onboard.sh:70-71, 94-95, 141, 167).

All three are named in CLAUDE.md as secret locations, so they are KNOWN -- they are simply outside the control. This materially extends SEC-023.

Related: runbooks/phase-01-bundle-deploy.md:391-410 writes overlays/octavia-pki.yaml containing base64 CA key blobs plus the issuing-CA passphrase in plaintext, inside the repo clone (gitignored). Given SEC-004 (repo currently PUBLIC), that gitignore is the only thing standing between a CA private key and publication.

FINDING 3 -- highest-concentration mint sites (matrix seeding order)

1. scripts/site-headend-install.sh -- 7 mints (:418 primitive, :430 DB pass, :445 rack-enrollment secret, :450/:452 admin password, :453 API key, :485 LXD trust). Every Office1/DC-region MAAS + LXD secret originates here.
2. scripts/tenant-onboard.sh -- 7 mints, the entire tenant identity set.
3. runbooks/phase-01-bundle-deploy.md:299-410 -- 8 Octavia PKI artifacts.
4. runbooks/tenant-onboarding-v2-DRAFT.md:162-320 -- 6 mints DUPLICATING #2 (two creation locations, one credential set -- do not double-count).
5. runbooks/phase-02-vault-bringup.md:71-144 -- 4 mints incl. the root of trust.
6. runbooks/dc-dc-phase4-juju-bundle-per-dc.md:119-151 -- 4 mints PER DC.

FINDING 4 -- corroborations of already-recorded defects

• dc-dc-phase4-juju-bundle-per-dc.md:128 mints juju-<dc> via maas createadmin with no --password, so MAAS prompts and the value is stored nowhere -- independently confirming the SEC-020 finding about those two superusers.
• site-headend-install.sh:452 uses --password in argv, the exposure SEC-020 flagged and which this session's operator mint avoided via stdin.
• scripts/phase-03-admin-openrc.sh:46-52 is classified MATERIALIZE (charm-generated, operator-materialized) -- exactly the case the ruled materialization test captures and a generation-based test would have missed (SEC-023).

What this means for the matrix

The matrix must carry a mint-ref column that can hold three provenance kinds, not one: script:line, runbook:step, and operator-terminal (undocumented). Finding 1 means a meaningful fraction of today's estate is the third kind, so a checker that requires every row to name executable code would fail 12 rows on day one. Those rows are the backlog the matrix exists to surface -- they should be admitted as operator-terminal and tracked as a debt to convert, not treated as parse errors.

Source: three read-only Explore agents, 2026-07-25. The full per-row tables ARE NOW IN THIS FILE (see APPENDIX below), transcribed 2026-07-26 before the originating session was cleared -- they are the creds-matrix.tsv seed and must not depend on a transcript.

APPENDIX -- full per-row inventory (the matrix seed)

Transcribed into the repo 2026-07-26 because the body above pointed at a session transcript that was about to be cleared. These rows ARE the creds-matrix.tsv seed; they are what docs/D-137-implementation-plan.md step 3 tells the build to read. Classification: MINT = new secret material; MATERIALIZE/UPLOAD excluded (section E).

A. Scripted MINT points (repo code generates the secret)

B. Runbook / prose MINT points (operator by hand; no script owns it)

D. Charm/platform-minted at bundle apply (no repo mint site)

• Keystone admin password -- charm-minted; MATERIALIZED by phase-03-admin-openrc.sh:52 via juju run keystone/leader get-admin-password + extract_admin_password.py. In matrix scope per the materialization ruling.
• Per-service DB / RabbitMQ / Ceph keyring credentials -- charm relation data, never materialized. OUT of scope (56 apps, zero hardcoded secret options in bundle.yaml).
• Vault-issued per-service TLS certs -- cascade from B4; phase-04-internal-cert-san-verify.sh verifies, does not mint.

E. MATERIALIZE / UPLOAD -- checked and EXCLUDED (not creation points)

phase-03-admin-openrc.sh:46-52,66-80 (writes ~/admin-openrc, SEC-023); extract_admin_password.py; phase-06-kubeconfig-gate.sh:36,59-77; phase-07-conductor-graft.sh:121-129 (base64 to the conductor unit, sha256-verified); phase-06-net-setup.sh:23,48 and phase-06-incloud-mgmt-cluster.md:206 (UPLOAD of an existing pubkey); opentofu/main.tf:218-219,444-447,575-578 (cloud-init ssh_authorized_keys via file()); vr1-dc{0,1}-substrate/main.tf:21,18 (qemu+ssh?keyfile= -- path only, D-126 boundary); opnsense-api.sh:32,75 (consume); reenroll-hosts.sh:122-123 (read -rsp a libvirt password into MAAS power params -- rotation warning :22-25); vault-kv-inner-probe.sh:12-13,22 (consume); site-ssh-config.sh / site-forward.sh / site-baseleg.sh (explicit no-key-material boundaries); netbox/*.py (consume NETBOX_TOKEN from env only); creds-audit.sh (metadata only); .claude/hooks/guard-destructive.py:28-42; snapshot_scrub.py:10.

G. Coverage boundary

Searched beyond scripts/+runbooks/: bundle.yaml, overlays/, clientdocs/ (incl. scripts/ and tenant-skill/), policies/, skills/, .claude/, creds-manifests/, _handoff-not-committed/. tests/ EXCLUDED as fixtures (tests/tenant-onboard/run-tests.sh:21,86 mints a fake CA/PEM; test_logic.py uses NETBOX_TOKEN="fake-token") -- no real credential originates there. NEVER opened, and excluded from content-printing greps: opentofu/terraform.tfstate*, the 8 *.tfplan, logs/, asbuilt/, docs/audit/, netbox/draft/*.json. opentofu/README.md + variables.tf:6-10 confirm maas_api_key reaches tfstate in plaintext (DOCFIX-175) -- a secret-at-rest location with no mint of its own.