SOPS and KMS with IAM all together - missing guide?

[kingdonb]

Also related, (is it a guide I'm talking about, or a use case? Why not both...)

• Sections "Guides" and "Use cases" overlap #717
• validate.sh error "sops: Additional property sops is not allowed" flux2-kustomize-helm-example#48

It came up the topic of validate.sh and skipping secrets. That's a separate topic and I'll open more issues to avoid conflating them all, here I thought we might be missing a guide, can these tools all be used together productively, and should we have a full example that demonstrates that, if we think so? SOPS + KMS with IAM for source repo authorization, used for environment secrets.

I think we should probably have better coverage of the way that SOPS and KMS can be used productively together. We already cover these topics separately, KMS is covered in the SOPS guide, and cloud-specific guides for AWS, Azure, and Google are available that all address private source repositories through ambient credentials.

There's no doc though today that discusses to build an access-controlled repo for secrets, only authorized by the cloud provider's IAM, and storing the SOPS-encrypted secrets there; using a KMS key to encrypt that secret data in the repo with SOPS for KMS. Is this a good pattern that we should promote, or is it an anti-pattern keeping secrets in Git at all?

I know there are some Flux (Kustomize) features that you can only access when the secret is kept in the repo together with the deployment configuration or HelmReleases etc.

Perhaps this is a guide that belongs in another separate repo: we've been having a related conversation over at fluxcd-community/github-app-secret - though not as focused on documentation, more practically focused around GitHub as an identity provider.

[kingdonb]

For some groups / architecture decisions / the idea of secrets in the repo will get rejected to even think of doing this way, since git repos are not key vaults I think many will opt not to keep secrets there, even encrypted. That's a fine policy but...

If we cannot stop the users from committing secrets accidentally, (or maybe we can)

• Guide: How to prevent secrets committed in the repo #1482

It would be good to mention in an existing guide also: kubeconform takes the option -skip=Secret

[kingdonb]

I think the SOPS guide should be expanded to cover more generally, use with KMS and IAM to keep KMS-protected secrets that are SOPS-encrypted in the IAM-authorized repository. (If this gets too large and far off-topic for Flux itself, maybe it belongs in Weave GitOps instead. If there isn't agreement about how it should work, that's a different problem and I'd like to talk more about it.)

Then again, maybe what I'm looking for isn't a new guide, maybe it's a product feature that just doesn't exist yet. I think there are some goals around this area that have been better explored from a product perspective in Weave GitOps. A button that users click on is always going to reach more people than a long drafty guide covering .... xyz, etc.

Trying to think of what is the ideal experience for secrets management with Flux, if we can assume you have the UI to support creating a secret or if we need to guide users through how to create a repo and make it secret with keys rotation, all processes that people talk about but rarely if ever implement unless they are statutorily bound. It would be good to find a real way to help our users with that issue.