The proliferation of these type of projects clearly shows the need for secret handling. While I think that more solutions for the same problem is not a bad thing, I also believe that we could benefit from a coordinated effort.
My colleagues are actively working with GoDaddy's maintainers to find a common way forward by standardizing the "ExternalSecret" CRD and eventually merging the projects.
Instead, the standard solution today is custom integration, which leads to a lot of reinventing the wheel and incompatibility with extremely similar products.
People need solutions to their problems and they develop them asynchronously and in isolation from each other. Turns out that some problems are more universal than others and could benefit from a common effort.
Suddenly, solutions collide and collaboration happens. What you describe is exactly what they are trying to do now: https://github.com/godaddy/kubernetes-external-secrets/pull/...
So, rejoice! The magic of open source and internet enabled collaboration is happening right before your eyes! :)
1. It's the exception, not the rule. Most of the time there aren't collaborative solutions. Most of the time people work in their silos and make something work for themselves. Often it's corporate-funded, and those corporations have no consideration for others being able to pick up the work once they've abandoned it. The fact that there's 10 of the same thing to integrate is proof enough. It's just gotten so ridiculous that somebody finally had to address it. Turns out it's a company that has to deal with all of those implementations anyway.
2. This is one tool figuring out how a bunch of other tools can integrate into it. It's like what I'm proposing, if you assume the least work possible to achieve maximum laziness for your own specific tool and use case.
Their solution wasn't "hey, it looks like a lot of things use secrets. maybe it'd be cool if we made one way for any system with secrets to interoperate with any other system, and try to get it adopted by existing vendors." Their solution was "hey, we just need to get all these other things to work for the one tool we're using." Rather than "how can we make this more composable, more compatible, easier to implement, for everybody... even if they're not using our tool...", it became "how can we make this easier for just us?"
That's what is always happening, has always been happening, in this space, for nearly 10 years. Either everybody latches their custom tech onto a single platform and no real open source solutions get made, or everybody spits out incompatible, overbuilt, underthought, opinionated solutions for their own problem. We don't build standard solutions in the cloud world, we build log cabins.
I mean, just read the PR. They're talking about coding into this 'standard' support for each different implementation. Like "this is a vault secret, and this is a gsm secret." That's the opposite of what I want. I want it to say, "this is what a secret looks like. now you figure out how to use it.", or, "give me your secret. I don't care who or what you are, because we all speak the same secret language." That is what an internet standard is supposed to be. Not "this is a bind9 DNS record, this is an AD DNS record, this is a RedHat DNS record, this is a Route53 DNS record".
The "container landscape" shouldn't remotely resemble what it does today. The idea of a "container" should have been standardized in an agnostic way, without requiring all the (admittedly useful, but also completely unnecessary, and often burdensome) features Docker threw into their tool. Yes, many people's lives were made easier. But a whole lot of other lives were made harder, to the point of small economies built out of badly re-implementing and custom-integrating into one precious and incompatible concept.
I would call Kubernetes the open source Active Directory, but Active Directory is literally ten times more standards compliant.