railiance-infra/docs/sops-rotation.md
codex b93af8cc78
Some checks failed
CI Smoke / source-contract (push) Failing after 2s
CI Smoke / host-smoke (push) Successful in 0s
CI Smoke / container-smoke (push) Successful in 1s
Implement reproducible S1 handoff contracts
Assistant: codex
Assistant-Model: gpt-5.6-sol
Assistant-Session: 01a02994-7685-7940-bf34-3555b8256018
2026-08-23 12:02:23 +02:00

1.2 KiB

Bounded SOPS Recipient Rotation

The default operation is metadata-only and does not decrypt values:

python3 scripts/sops_rotation.py --check

It compares each protected file's public age-recipient metadata with the first matching rule in .sops.yaml. CI runs this check to detect recipient drift.

An attended non-printing decryption check may emit a receipt:

python3 scripts/sops_rotation.py --check --verify-decryption \
  --receipt reports/sops-rotation-check.json

Decrypted bytes go directly to the null device. They are not retained in the receipt or command output.

Actual key updates require --apply and an approval YAML containing approved: true, approved_by, approved_at, and an exact changes list from the current plan. The command fails if that list differs from current metadata. Review and preserve recovery-key custody before approving recipient removal. Start from docs/sops-rotation-approval.example.yaml; the committed example is deliberately unapproved and contains no usable recipient.

Rollback is a reviewed restoration of the prior .sops.yaml recipient set followed by the same exact-plan approval, sops updatekeys, and non-printing decryption verification. Git history alone is not recovery-key custody.