Thoughts on moving this project to the @getsops org?

[Gowiem]

This operator is fantastic. My team and I have used it on a few different projects with a lot of success. Now that SOPS is a part of the CNCF and they have their own org @getsops, is there any intention to move this project there where it could get more visibility / official support?

[isindir]

@Gowiem that is interesting. I'm not sure if @getsops org would be interested in this, there is certain specific blocker:

• https://github.com/isindir/sops-secrets-operator?tab=readme-ov-file#known-issues

and more context for this is here:

• https://github.com/getsops/sops/issues/783

Main two reasons behind this operator to ignore mac signature are:

• if I try to use it as is - k8s mutates object in cluster and signature becomes invalid
• if I wrap encrypted secret into some field of higher level abstraction - e.g. base64 encoded encrypted secret, the CRD partly looses its value - transparency for users who do not have privileges to decrypt this data and simplicity of changing. With current CRD these users are able to see keys, but not values, which may help to understand application config without leaking secrets at the expense of verification of the actual encrypted artifact.

This was a deliberate decision of mine to simplify usage without loosing transparency and simplicity, but conflicts with upstream sops ideology. An alternative to how I manage secrets is done in here: https://github.com/craftypath/sops-operator , however in my mind it improves security on behalf of making it more complex to manage CRs (with this operator one can just use sops cr.file.name.yaml to make changes).

Also I have originally written this operator for flux v1, but flux v2 now supports sops out of the box - https://fluxcd.io/flux/guides/mozilla-sops/ .

This operator perhaps still have some niche use cases, but generally I'd advise using more sophisticated methods of managing secrets in k8s gitops environment. For example, external secrets have some interesting features - like cluster wide secrets and secrets which are dynamically generated, for example for AWS ECR access.

I hope this answers your question ? 🤠

[Gowiem]

@isindir it does. The first thing that comes to mind is I wonder if some of those issues could be fixed with optional functionality that could be added to the upstream SOPS tool. But in general it is interesting to hear you suggest other options instead of this operator. Maybe I need to check out sops-operator more. I know of external-secrets, but maybe it has come along where it's more of interest.

Anyway, thanks for sharing your thoughts!

[Gowiem]

Ah in a quick look at sops-operator it seems far off from what you've provided in this operator! No legitimate documentation + no code changes in 2 years is a very quick deal breaker for me at least.