# vr1-dc0 creds manifest -- what MUST be consolidated in ~/vr1-dc0-creds/ (SEC-009 + D-126).
# scripts/creds-audit.sh verifies this list against the live folder: presence, mode,
# non-empty. No secret VALUES are read -- only existence, mode, and declared provenance.
#
# fields:  <filename>  <octal-mode>  <source>
#   source = "local"        -- generated/held on the jumphost (vcloud)
#          = "<vm>:<path>"   -- MINTED ON A SITE VM; a working copy MUST be pulled into
#                              the folder at mint time.
#
# STATUS: the access keypair below is MINTED (2026-07-16, on vcloud) -- generated EARLY (not at
# deploy) because vvr1-dc0's cloud-init reads the pubkey with file() at plan time (D-126 per-env-key
# option a: a DEDICATED dc0 key, NOT office1's). `creds-audit vr1-dc0` -> CLEAN.
# vr1-dc0*.env files (e.g. TF_VAR_* / MAAS) are ADDED to this manifest as the dc0 deploy
# design determines them -- not invented here (hard rule 2).

vr1-dc0_svc_ed25519         600  local
vr1-dc0_svc_ed25519.pub     644  local
# Edge service keypair (D-112(c) console bootstrap; minted on vcloud at the dc0
# edge-bootstrap step). BACKFILL 2026-07-25: these rows were the queued finding
# named in creds-manifests/vr1-dc1.manifest -- dc1 declared its equivalents at
# mint time, dc0's never were, so both showed as UNDECLARED creds-audit FAILs.
vr1-dc0-edge_ed25519        600  local
vr1-dc0-edge_ed25519.pub    644  local
# Dedicated dc0 MAAS admin API key for the Juju cloud credential (SEC-018;
# MAAS superuser juju-vr1-dc0). Generated FROM the jumphost 2026-07-24 so it
# never persisted on the region -- hence provenance "local", not a <vm>:<path>.
# A runtime copy also lives in Juju's client credential store on voffice1
# (off-manifest -- that store is not this folder). Declared 2026-07-25.
maas-api-key.txt            600  local
# Dedicated MAAS->libvirt power key (SEC-012, per-DC isolation; minted 2026-07-20
# at the step-D power wiring). CONSOLIDATED 2026-07-27 -- the SEC-021(b) remediation:
# "dc0's key should gain a jumphost copy + manifest row". PROVENANCE, stated here
# because the machine field cannot carry it: dc0's key had NO jumphost copy at all,
# so this pair was NOT generated on vcloud. The private half was copied from the
# voffice1 shadow store (~/vr1-dc0-creds/maas-virsh_ed25519, the SEC-022 class),
# sha256-verified byte-identical at both ends; the public half NEVER EXISTED
# anywhere and was DERIVED here with `ssh-keygen -y`, its fingerprint verified
# equal to the key installed in the region MAAS snap (SHA256:Dt/YXTXSF4nXGj9cz8f0
# owL+qreVpMYBVm/igW10FXY). Provenance reads "local" (held on the jumphost) to stay
# consistent with `creds-matrix.py --render`; the sentences above are the record.
# NAMED for its purpose, per SEC-021(b)'s "reconciliation to the dc1 shape". The
# key's own INTERNAL comment still reads "maas-virsh-pod (D-123 amendment)" -- it
# was minted for the qemu+ssh POD attempt that was REFUTED the same day, and the
# per-machine `power_type=virsh` ruling correctly retained the dedicated key. The
# stale comment is cosmetic and was NOT rewritten (that would alter key material);
# the file name is now authoritative. This copy is also what SEC-012/-016's snap
# fragility needs: /var/snap/maas/current/ is per-revision, and dc0 previously had
# no jumphost copy to re-assert from after a snap refresh.
vr1-dc0-maas-power_ed25519      600  local
vr1-dc0-maas-power_ed25519.pub  644  local