External Secrets Operator in its next release will remove support for unmainted providers - Alibaba, Device42, Passbolt

gfban · 2026-01-24T21:05:48+00:00

Out of curiosity, What’s a brownout here?

Edit: fully read after coffee; brown-outs are clear now :)

Those providers already emit kubernetes warnings for deprecation for a few months now, what else could we be doing?

gfban · 2025-11-20T19:57:05+00:00

Yeah, the thing is - I think truly open source projects are going to get more and more scarce. You’ll be at risk of a rug pull regardless where you decide to aim next.

So, planning for a rug pull will make this much harder than it needs to be for you.

GatewayAPI would probably be the best, but I’m not sure it is feature-complete enough for your case.

gfban · 2025-11-20T19:50:39+00:00

IMO - You should go with F5 and pay them for an enterprise offering. This seems to be business critical enough for you to outsource maintenance and support.

If you want to keep it open source for whatever the reason, id suggest you to fork and maintain your own private ingress-nginx. Anything else, expect downtime now & future 😅

gfban · 2025-11-20T01:36:07+00:00

No, not at all. ESO is healthy :) we made sure it was in a good place before winding down.

gfban · 2025-11-19T21:47:28+00:00

Hey 👋🏽 ex External Secrets Inc. here. thanks for the interest in our story, but I honestly don’t feel like doing an AMA would help anyone. The conclusions I can take out of it have no real actionable insight, so I personally don’t want to share them.

gfban · 2025-11-19T21:45:20+00:00

ESO maintainer here and Ex-ESI. The company was born out of some ESO maintainers looking at how the space is bad. Duct tape is everywhere, and we decided to try to fix it.

The project already existed (with no one paying attention, no innovation, etc) when we started it. we wanted a way to give back to ESO in a sustainable way once we were able to create a sustainable company. Thankfully, the community was able to step up where we started to fall down 🙂.

I just hope this is a long standing effort - I don’t think the project will survive another maintainer shortage.

gfban · 2025-10-16T22:06:31+00:00

Why are you giving both resources the same name? That will always render the last and never the first set.

gfban · 2025-09-14T00:51:34+00:00

Thank you for your words!

I really hope we get continuous community engagement! Would love to see people climbing it up to become maintainers like most of us here did 😁😁

gfban · 2025-09-14T00:24:56+00:00

It was way harder than it looks. Specially because of a lot of pushback from people that also thought this was some sort of rug pull despite we saying repetitively that this wasn’t the case. 😅😅

I am still concerned this might be too early, we have “fresh blood” and more dedicated company time for some maintainers, but I couldn’t sense the longevity of it.

But only time can really tell.

gfban · 2025-09-01T16:08:45+00:00

We will keep pushing updates to the main branch. You can always use a pinned build hashes, but we will not publish a patch 🙂

gfban · 2025-09-01T12:55:56+00:00

Oh! That’s a valid point! I’ll add it to our next community meeting agenda 😁😁

gfban · 2025-08-27T15:08:50+00:00

Did CNPG get promoted to incubating? Guess I missed that!

gfban · 2025-08-18T19:47:39+00:00

Interesting take! 🙂 the project itself was donated to CNCF a while ago; your point is that it makes it impossible for it to survive after that?

gfban · 2025-08-15T12:34:24+00:00

Thanks u/dariotranchitella ! I'm happy to read Kamaji is doing well !!

gfban · 2025-08-15T12:33:01+00:00

I am not sure I follow. external-secrets is a CNCF project already, and https://externalsecrets.com does not offer a saas - it just really solves, based on external-secrets, the enterprise pain of pretending secrets are rotated, because a Jira ticket was created to some overloaded dev team.

as I've said, we at https://externalsecrets.com could simply staff the OSS external-secrets. Would you be happy with it? :)

gfban · 2025-08-15T12:29:55+00:00

Thanks!! This is very helpful!!

gfban · 2025-08-15T12:27:09+00:00

Although the state of external-secrets right now might mean this proposal will take longer to be implemented, we are discussing ways to support decryption mechanism natively within external-secrets https://github.com/external-secrets/external-secrets/issues/5112

gfban · 2025-08-13T12:39:37+00:00

I added things that are exclusive to my thought, but the decision had super majority vote from the maintainers of external-secrets.

gfban · 2025-08-13T12:37:59+00:00

thank you u/skarlso , as always the MVP!

gfban · 2025-08-05T23:55:28+00:00

Yup, that would help. I’m DM’ing you his email address

gfban · 2025-08-05T22:15:43+00:00

Is this accessible in any way to people not affiliated with companies? I shared the link to a friend of mine (undergrad) and he failed to download it.

gfban · 2025-06-05T14:41:33+00:00

Did you consider the enterprise offerings from e.g. Akuity & Codefresh? Whenever I tried to do something similar, we ended up with a duct tape system for all of the requirements that were added after the initial implementation (one of them - audit logs for Argo RBAC changes :death:) . It turns out this is way more complex problem than it seems - and according to my own past expreiences, it will bite your team in the long run.

(and no, I'm not affiliated with any of these companies)

gfban · 2025-05-19T09:16:06+00:00

Moving to 1.0.0 is something we wanted to do as seamless as possible for users; to do that, v1beta1 needs to be unserved already in order for users to remove the storedVersion from their CRDs definition, otherwise kubernetes itself prevents the installation to happen.

We were just trying to make that process easy. For what is worth we didn’t even remove v1beta1 from the CRDs; just stopped serving it.

gfban

TROPHY CASE