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

New issue

Closed

opened 2026-07-01 19:36:59 +01:00 by nimmo · 0 comments

nimmo commented

2026-07-01 19:36:59 +01:00

Owner

Context

All secrets currently share one broad recipient group, so any registered host key can decrypt secrets unrelated to that host. The impact grows as more service credentials are added.

Relevant files:

.sops.yaml
secrets/secrets.yaml

Scope

Design host- or service-scoped recipient groups while preserving emergency YubiKey/provisioning access.
Split secrets when the current file becomes unwieldy or before materially more sensitive services are added.
Remove stale host recipients promptly after retirement.
Prefer one encrypted env file per service/host or Newt instance where that keeps the secret inventory clearer than many scalar keys.

Completion criteria

Hosts can decrypt only the secrets they require, except for explicitly documented emergency recipients.
Service modules use the narrower secret files successfully.
Recipient rotation and host-retirement procedures are documented in the wiki.

Dependency

Blocked by #80 (Split secrets.yaml into scoped per-service/host files with narrowed SOPS recipients). The recipient-scoping work here rides on top of the file breakup; there is nothing to narrow until the monolithic secrets.yaml is split. The formal Forgejo dependency link could not be set via available tooling, so it is recorded here.

## Context All secrets currently share one broad recipient group, so any registered host key can decrypt secrets unrelated to that host. The impact grows as more service credentials are added. Relevant files: - `.sops.yaml` - `secrets/secrets.yaml` ## Scope - Design host- or service-scoped recipient groups while preserving emergency YubiKey/provisioning access. - Split secrets when the current file becomes unwieldy or before materially more sensitive services are added. - Remove stale host recipients promptly after retirement. - Prefer one encrypted env file per service/host or Newt instance where that keeps the secret inventory clearer than many scalar keys. ## Completion criteria - Hosts can decrypt only the secrets they require, except for explicitly documented emergency recipients. - Service modules use the narrower secret files successfully. - Recipient rotation and host-retirement procedures are documented in the wiki. ## Dependency **Blocked by #80** (Split secrets.yaml into scoped per-service/host files with narrowed SOPS recipients). The recipient-scoping work here rides on top of the file breakup; there is nothing to narrow until the monolithic `secrets.yaml` is split. The formal Forgejo dependency link could not be set via available tooling, so it is recorded here.

nimmo added this to the Security Hardening milestone

2026-07-01 19:36:59 +01:00

nimmo added the

project:security-hardening

host:fleet

labels

2026-07-01 19:36:59 +01:00

nimmo referenced this issue

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

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

nimmo added reference feat/split-scoped-secrets

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