Encrypted files that match no sops creation rule, and stale rules for retired hosts #321

New issue

Open

opened 2026-08-10 17:06:43 +02:00 by dominik.polakovics · 0 comments

dominik.polakovics commented

2026-08-10 17:06:43 +02:00

Owner

Follow-up carved out of #319 (PR: /pulls/320), which deliberately left both of these alone so a pure rename stayed a pure rename.

1. Three encrypted files match no creation rule

hosts/web-arm/modules/bitwarden/secrets.sops.yaml
hosts/web-arm/modules/nextcloud/secrets.sops.yaml
utils/modules/plausible/secrets.sops.yaml

The first two sit one directory below the deepest hosts/web-arm/ rule; utils/modules/plausible/ never got a rule at all (unlike its siblings lego, alloy, attic-cache, victoriametrics). Consequence: ./scripts/update-secrets-keys attempts all three and sops updatekeys fails on each, so a key rotation cannot complete cleanly. This predates #319 — the old discovery found them too.

The bitwarden and nextcloud files look dead: both modules resolve their secrets through hosts/web-arm's defaultSopsFile, and grep finds no sopsFile reference to either. They date to f86996cd ("add zammad to fw vm, add web-arm machine"). If that holds, delete them. utils/modules/plausible/secrets.sops.yaml is live (utils/modules/plausible/default.nix:5,8) and needs a real rule.

Verify before acting — this needs someone with the age keys, which an agent sandbox does not have.

2. Stale creation rules and key anchors for retired hosts

gpd-win4, fw-new, netboot, web-02, ldap-server-arm still have creation_rules entries and keys: anchors in .sops.yaml. #319 tightened their regexes along with everything else but did not remove them, because removing a recipient is a re-encryption and wants its own review. Note web-02 and ldap-server-arm still appear in the recipient sets of live rules (utils/modules/lego/, alloy, victoriametrics, hosts/mail/, hosts/fw/vms/web/), so this is not a pure deletion — dropping them re-encrypts those files.

Both parts require sops and the private keys, so this is likely ready-for-human.

Follow-up carved out of #319 (PR: /pulls/320), which deliberately left both of these alone so a pure rename stayed a pure rename. ## 1. Three encrypted files match no creation rule ``` hosts/web-arm/modules/bitwarden/secrets.sops.yaml hosts/web-arm/modules/nextcloud/secrets.sops.yaml utils/modules/plausible/secrets.sops.yaml ``` The first two sit one directory below the deepest `hosts/web-arm/` rule; `utils/modules/plausible/` never got a rule at all (unlike its siblings `lego`, `alloy`, `attic-cache`, `victoriametrics`). Consequence: `./scripts/update-secrets-keys` attempts all three and `sops updatekeys` fails on each, so a key rotation cannot complete cleanly. This predates #319 — the old discovery found them too. The bitwarden and nextcloud files look **dead**: both modules resolve their secrets through `hosts/web-arm`'s `defaultSopsFile`, and `grep` finds no `sopsFile` reference to either. They date to `f86996cd` ("add zammad to fw vm, add web-arm machine"). If that holds, delete them. `utils/modules/plausible/secrets.sops.yaml` **is** live (`utils/modules/plausible/default.nix:5,8`) and needs a real rule. Verify before acting — this needs someone with the age keys, which an agent sandbox does not have. ## 2. Stale creation rules and key anchors for retired hosts `gpd-win4`, `fw-new`, `netboot`, `web-02`, `ldap-server-arm` still have `creation_rules` entries and `keys:` anchors in `.sops.yaml`. #319 tightened their regexes along with everything else but did not remove them, because removing a recipient is a re-encryption and wants its own review. Note `web-02` and `ldap-server-arm` still appear in the recipient sets of *live* rules (`utils/modules/lego/`, `alloy`, `victoriametrics`, `hosts/mail/`, `hosts/fw/vms/web/`), so this is not a pure deletion — dropping them re-encrypts those files. Both parts require `sops` and the private keys, so this is likely `ready-for-human`.

dominik.polakovics added the

needs-triage

label

2026-08-10 17:06:43 +02:00

dominik.polakovics referenced this issue

2026-08-10 17:18:29 +02:00

refactor(sops): encrypted files carry the .sops.yaml suffix #320