name: creds-folder-convention description: "Per-site credential/env consolidation on vcloud -- ~/-creds/ folders, no loose env files" metadata: node_type: memory type: project

originSessionId: 75c0e0cb-822c-4f42-ab63-04d3175865f4

All sensitive files AND environment/config files for a VR1 site live in ONE per-site folder on vcloud: ~/<site>-creds/ (dir 0700, files 0600, public keys 0644). NO loose *.env in ~.

• ~/vr1-office1-creds/ exists: SSH key, OPNsense api/root creds, tailscale key, and the env files vr1-netbox.env (upstream/v1-draft NetBox token), vr1-office1.env (edge config), vr1-stage1.env (OpenTofu TF_VAR_*, incl. TF_VAR_maas_api_key).
• When DC deployment starts, ~/vr1-dc0-creds/ and ~/vr1-dc1-creds/ follow the SAME pattern FROM DAY ONE -- do not let vr1-dc0*.env accumulate loose in ~ and consolidate later.
• PER-ENV ACCESS KEY (D-126, operator ruling 2026-07-16): each env gets its OWN SSH access key in its own creds folder -- office1 uses office1_svc_ed25519 (~/vr1-office1-creds/, one key across office1's 3 VMs); each DC gets a DEDICATED key (~/vr1-dc0-creds/, ~/vr1-dc1-creds/), NOT office1's, for per-env blast-radius isolation. DC keys are minted at DC deploy (pubkey -> DC cloud-init), not early. The agent reaches these via scripts/site-ssh-config.sh (ssh_config ProxyJump aliases; office1 shell access EXERCISED/working). See [[review-after-each-step]] discipline when adding DC rows.

This is a DATA-LOSS / continuity control first, security second: scattered creds get lost between sessions and after compaction. Established 2026-07-15 (SEC-009) after three env files were found loose in ~, one (vr1-stage1.env) holding a MAAS API key at world-readable 0664.

The SANDBOX NetBox token is NOT on vcloud -- it lives on office1-netbox at /root/netbox-secrets/ (v2 wire form nbt_<key>.<plaintext>). vr1-netbox.env is the UPSTREAM token only.

Ties to [[project-posture-closed-test]] (why security hygiene is data-loss-framed, not lockdown).