Split secrets.yaml into scoped per-service/host files with narrowed SOPS recipients #80

New issue

Closed

opened 2026-07-20 15:51:19 +01:00 by nimmo · 0 comments

nimmo commented

2026-07-20 15:51:19 +01:00

Owner

Context

secrets/secrets.yaml is still a single ~19 KB monolithic file holding keys for many unrelated services and hosts. A breakup is already partly underway (separate ai-tools.yaml, attic.yaml, bookstack.yaml, git.yaml, mem0.yaml, nebula-ca.yaml, newt.yaml, pangolin.yaml, sabnzbd.yaml, trilium.yaml already exist), but the remainder lives in secrets.yaml and .sops.yaml still grants every host the ability to decrypt every secrets/*.yaml.

This issue is the implementation track for #39 (split SOPS recipients and secrets by host/service scope). #39 depends on this work existing to scope against.

Scope

Migrate the remaining keys out of the monolithic secrets.yaml into per-service or per-host files (one encrypted env file per service/host or Newt instance where that keeps the inventory clearer than many scalar keys).
Restructure .sops.yaml creation_rules so each file's recipient group is the consuming host(s) plus the admin keys:
- both YubiKeys (yubikey-nano5c, yubikey-5-nfc) — already present in every group; these are the everyday admin escape hatch for sops edit from any workstation.
- the provisioning age key (in password manager) — currently a universal recipient; reconsider whether it should stay universal or be scoped down like host keys.
Keep the broad secrets/.*\.yaml group only as a fallback for anything not yet migrated.
Remove stale host recipients promptly after retirement.
Update the wiki with recipient-rotation and host-retirement procedures.

Admin / manageability model

Strict host-scoping does NOT block secret management: the YubiKeys are recipients on every file, so sops edit works from any workstation with a YubiKey present (Nano 5C is everyday, 5 NFC is backup). Hosts are consumers, not the only editors.

Completion criteria

No sensitive keys remain in the monolithic secrets.yaml (or it is emptied/deleted).
Each secret file decrypts only on its consuming host(s) plus the admin YubiKeys (and provisioning key, pending the scoping decision).
Service modules reference the narrower files successfully; nix flake check passes and hosts activate.
Recipient rotation / host-retirement procedure documented in the wiki.

Dependency

#39 depends on this issue.

## Context `secrets/secrets.yaml` is still a single ~19 KB monolithic file holding keys for many unrelated services and hosts. A breakup is already partly underway (separate `ai-tools.yaml`, `attic.yaml`, `bookstack.yaml`, `git.yaml`, `mem0.yaml`, `nebula-ca.yaml`, `newt.yaml`, `pangolin.yaml`, `sabnzbd.yaml`, `trilium.yaml` already exist), but the remainder lives in `secrets.yaml` and `.sops.yaml` still grants **every** host the ability to decrypt **every** `secrets/*.yaml`. This issue is the implementation track for #39 (split SOPS recipients and secrets by host/service scope). #39 depends on this work existing to scope against. ## Scope - Migrate the remaining keys out of the monolithic `secrets.yaml` into per-service or per-host files (one encrypted env file per service/host or Newt instance where that keeps the inventory clearer than many scalar keys). - Restructure `.sops.yaml` `creation_rules` so each file's recipient group is the consuming host(s) **plus the admin keys**: - both YubiKeys (`yubikey-nano5c`, `yubikey-5-nfc`) — already present in every group; these are the everyday admin escape hatch for `sops edit` from any workstation. - the provisioning age key (in password manager) — currently a universal recipient; reconsider whether it should stay universal or be scoped down like host keys. - Keep the broad `secrets/.*\.yaml` group only as a fallback for anything not yet migrated. - Remove stale host recipients promptly after retirement. - Update the wiki with recipient-rotation and host-retirement procedures. ## Admin / manageability model Strict host-scoping does NOT block secret management: the YubiKeys are recipients on every file, so `sops edit` works from any workstation with a YubiKey present (Nano 5C is everyday, 5 NFC is backup). Hosts are consumers, not the only editors. ## Completion criteria - No sensitive keys remain in the monolithic `secrets.yaml` (or it is emptied/deleted). - Each secret file decrypts only on its consuming host(s) plus the admin YubiKeys (and provisioning key, pending the scoping decision). - Service modules reference the narrower files successfully; `nix flake check` passes and hosts activate. - Recipient rotation / host-retirement procedure documented in the wiki. ## Dependency #39 depends on this issue.

nimmo added this to the Security Hardening milestone

2026-07-20 15:51:19 +01:00

nimmo referenced this issue

2026-07-20 15:51:43 +01:00

Split SOPS recipients and secrets by host or service scope #39

nimmo referenced this issue

2026-07-29 21:42:30 +01:00

refactor: split scoped secrets and narrow SOPS recipients #122

nimmo added reference feat/split-scoped-secrets

2026-07-29 21:49:40 +01:00

nimmo closed this issue

2026-07-29 22:23:29 +01:00