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

31 lines
1.2 KiB
Markdown

# Bounded SOPS Recipient Rotation
The default operation is metadata-only and does not decrypt values:
```bash
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:
```bash
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.