Figre a good "gitops" way to handle secrets. As of this writing, using Bitanmi Sealed Secret but don't play all that well with Kustomize's secretGenerator (mainly the hash providing auto rolling deployments when secrets change). Ideas
Super-simple: Have a configmap, managed through configmapgenerator, that has a value that will force a rolling update when a secret changes. Not QUITE automate though...
Reloader. Will watch for configmap/secrets changes. Given they provide a kustomize manifest, I would presume it would work with Kustomize. They have explicit instructions for working with SealedSecrets
Sops: Certainly would work, but might need to bake more tooling around build pipelines as it get's more automated. Perfer something more baked into the cluster like SealedSecrets.
Closing. Probably stick with Sealed Secrets and just use a named "version" as a secret should be immutable anyway (and not depend on kustomize's hash itself to provide such versioning)
Figre a good "gitops" way to handle secrets. As of this writing, using Bitanmi Sealed Secret but don't play all that well with Kustomize's secretGenerator (mainly the hash providing auto rolling deployments when secrets change). Ideas