Consider merging with External Secrets Operator

[riccardomc]

Hi there, I maintain a very similar project. Maybe we should find a way to join forces?

Take a look: https://github.com/ContainerSolutions/externalsecret-operator

[slamdev]

@riccardomc hi Riccardo! I know your project and you've done an amazing work there. I wanna contribute to your project at first, but didn't do it for couple reasons:

• seems like development is not really active atm
• lack of core features that were needed for my use case (multiple backends, multiple keys in a single secret)
• configmaps support

I analysed that it will require almost complete rework of your solution to meet my needs.

But I am happy to join forces and create a solution that suit us all!

I also found this issue external-secrets/kubernetes-external-secrets#47 where you discussing the "big merge". But discussion didn't go any further I guess.

We can either jump in there and see if others still share the same interest, or do it with two of us.

As a next step I suggest to schedule a call where we can define the strategy and a way to move forward.

[riccardomc]

Hi @slamdev , thanks for you reply! I believe that we have a good window of opportunity to build something cool.

Let me address your points one by one:

• this is a project I started in my 20% time at Container Solutions, I've been too busy with other work to add new things. I recently added a CONTRIBUTING.md guide and an architecture/design choices document. I would be very happy if you check it out!
• not having multiple backends is a design choice. I would rather have two operator instances with two separate backends and demand which namespaces are able to inject secrets into using RBAC and ServiceAccounts instead of writing the logic myself and get it wrong. At some point in time, it did support multiple backends, I then removed that feature! 😄
• when I started the project I actually wanted to call it "externalconfig-operator" and support ConfigMaps as well, I have nothing against implementing it.

The advantage of your project and the one I maintain is the fact that we provide a generalized solution for a common problem by implementing several backends. The other projects are either focused only on Vault or AWS Secrets Manager. But this is an issue that can be generalized and the backend can be abstracted exactly as you did for Consul and Vault.

The project I maintain has already some attention and a few users (~100 stars), so I would be very happy to implement the changes you need and merge the backends for Consul and Vault.

I am almost done with milestone 0.1.0 and after that we can decide the next milestone together, so I would be very happy to jump on a call. I sent you an invite to the email in your profile! Let me know if it works for you.

I see you're based in The Hague, so we are in the same timezone. I live in Amsterdam 😄

[Flydiverny]

Just to update here there is now an ongoing community effort in building a shared project https://github.com/external-secrets/external-secrets replacing KES, ContainerSolutions/externalsecret-operator
You can find us on the kubernetes slack https://kubernetes.slack.com/archives/C017BF84G2Y