docs: Add example for dealing with compromised key

[fhoekstra]

The order of operations in this scenario is very specific and error-prone. It would make sense to document this right here in this project.

I would appreciate any feedback and/or corrections!

[netlify]

✅ Deploy Preview for getsops ready!

Name	Link
🔨 Latest commit	33533f5
🔍 Latest deploy log	https://app.netlify.com/projects/getsops/deploys/6a1688e695bb48000886686e
😎 Deploy Preview	https://deploy-preview-34--getsops.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify project configuration.

[felixfontein]

Thanks for your contribution! I think it is a great idea to have a section on this in the docs. I've added two comments below, which are my personal ones; maybe someone else from @getsops/maintainers might want to comment on them?

Also note that currently there's a large reorganization happening (#31) which conflicts with tihs PR (and in fact with any other PR changing the documentation). I don't know how long it will take @getsops/maintainers to review that PR, so whether it makes sense to merge this one first and rebase the other, or the other way around.

[felixfontein]

While it is generally better to schedule the operations this way, doing it the other way is only a problem in two specific situations:

1. secret.sops.yaml file is checked in between the two sops calls above;
2. alternatively, the compromised key is with a cloud provider (AWS, Azure, GCP, HWC, Vault) which is compromised itself, so that the call to encrypt the document key actually stores that document key.

I'm not sure whether this should be mentioned, but it probably makes sense to mention that the resulting file should be checked in after performing the two above steps.

[fhoekstra]

Thanks for the feedback! I've added a line about committing and pushing the file after this.
I was thinking of the file getting checked in between those actions (and assuming a public repo etc), I have changed the wording to be more nuanced and added your comment as a footnote

[fhoekstra]

Also note that currently there's a large reorganization happening (#31) which conflicts with tihs PR (and in fact with any other PR changing the documentation). I don't know how long it will take @getsops/maintainers to review that PR, so whether it makes sense to merge this one first and rebase the other, or the other way around.

I am interested in this subject right now because of the move to post-quantum encryption. Currently waiting for FluxCD 2.9 to be released, and then a lot of Kubernetes users of SOPS will be looking at moving to post-quantum. I'm looking to do a simple how-to blog post on it either way, it would be nice if I could point at the official documentation for this process.

But I understand there's "always something" and I wouldn't want to slow down the docs improvement project.