Do a SealedSecrets SOPS plugin

[reegnz]

First off, I'd say this is great work! I really like the alternative to use SOPS instead of go-crypto that SealedSecrets operates with. There are people out there that would rather use cloud-provider hosted solutions for crypto instead of go-crypto, and your project gives me hope.

As for the future, I think it would be great if we could work on functionality that allows using SOPS with SealedSecrets, as that project is more widely used and easier to adopt by organizations because it's established popularity.

I've made some discussions last year around doing pluggable backends in SealedSecrets annd the maintainers were open to the idea: bitnami-labs/sealed-secrets#779
I think it would be great if we could collaborate in creating that plugin mechanism for SealedSecrets and make a SOPS plugin as it's first crypto provider.

I think it would benefit the community greatly.

Cheers!

[isindir]

@reegnz, thanks.

Could you please explain what specific issue are you trying to solve ?

Can it be achieved with the tools at hand (see list on main readme), if not - what is the main reasoning behind the idea of making a plugin/merging controllers ?

How merger would be beneficial to the existing users of each controller ?

I don't see a specific design was agreed in bitnami-labs/sealed-secrets#779 ?

If you wish, we can have a chat in Keybase (isindir).

Thanks

[reegnz]

The problem I'm trying to solve is getting secrets into our clusters in a way that is compatible with our gitops pipeline and our security policies. SealedSecrets is a good fit and is 90% there with it's features. It has an established community, trusted by companies, so it's easier to adopt in the enterprise. The only issue it has is that you cannot offload it's crypto to something like an HSM, and this is where a crypto backend utilizing SOPS would be great. If one could use SOPS to encrypt your secrets and have SealedSecrets work with it, then it's the best of both worlds.

I'm not really advocating for an outright merger. Working on a common SOPS back-end that both operators could utilize is really the course I'm advocating for. I think if one could extract the sops-secrets-operator backend into a shared plugin that we could then use for both operators, that would benefit the users of sealed-secrets besides your current user-base.

I think clearly SealedSecrets users have more to gain from this than your projects users, so it's a stretch asking you to plan for that, but then working on a crypto backend for an operator that has a much wider reach would definitely benefit more people in the end. So really I'm advocating for increasing the reach of your work.

Currently there's no specific design agreed upon, so I think there's a lot of wiggle-room on what the actual plugin mechanism could be.

I'm available on the kubernetes slack with the same handle in case you visit that place.