 |
VOOZH | about |
|
VOOZH | about |
We’re so glad you’re here. You can expect all the best TNS content to arrive Monday through Friday to keep you on top of the news and at the top of your game.
Check your inbox for a confirmation email where you can adjust your preferences and even join additional groups.
Follow TNS on your favorite social media networks.
Become a TNS follower on LinkedIn.
Check out the latest featured and trending stories while you wait for your first TNS newsletter.
Like far too many open source projects, we don’t give Kubernetes External Secrets Operator (ESO) enough attention. We just assume the program will be kept up-to-date and that it will always be there. That’s a big mistake. Recently, one of ESO’s maintainers wrote on Reddit that “the contributor base hasn’t scaled with the user base. Right now, a very small team of maintainers is responsible for everything.” Indeed, according to Rasheed Amir, CEO of Stakater, a Swedish Kubernetes consulting company, on LinkedIn, “There’s only one active maintainer left.”
In a word, “Ow!”
The result? At the time, the project essentially shut down. There would be no official support: no Slack, no GitHub discussions, and no new versions until at least five active maintainers step up.
This is a big deal. ESO has become a critical utility for securing secrets in Kubernetes environments. ESO is usually one of the very first add-ons deployed to Kubernetes deployments. The program serves as a bridge to securely sync secrets from external providers like AWS Secrets Manager, Azure Key Vault and HashiCorp Vault directly into Kubernetes.
When ESO connects to one or more external secret providers, it fetches sensitive data such as credentials, API keys or certificates via secure APIs. It then injects these secrets as native Kubernetes Secret objects so applications can securely access them during runtime. Since Kubernetes’ native secrets are stored in etcd and aren’t encrypted, ESO is vital for enabling secrets to live securely in external secret managers with features like audit trails and access controls.
ESO also supports real-time updates and automatic secret rotation. This means if a secret changes in the external system, ESO will update it inside Kubernetes automatically.
How did such an important project end up in such a state? Gustavo Fernandes de Carvalho, an ESO maintainer, explained on the ESO GitHub that the maintainers “have simply ‘too much to do.’ Our contribution number increases, the support request increases,” while the active community member numbers keep shrinking. Moreover, “our maintaining team is mostly burnt out.” He added, “Our only active maintainer these days is @Skarlso (Gergely Brautigam) – which is a bad sign. Last week, when he was on vacation, we had 0 Pull Requests merged, + 20 issues open (most of them support issues).”
This can not continue.
The remaining team has declared that until they have at least five maintainers, the project is frozen. There will be no new features, bug fixes or security patches. Oh, and as for mentoring “junior people to become maintainers,” they don’t have the time or the resources to bring them up to speed.
Since they first called for help, more than 300 people, de Carvalho reports, have volunteered to help. In addition, “We’ve spoken with the Cloud Native Computing Foundation , who shared guidance on ensuring long-term project health.”
However, he continued, “While we trust the new maintainers, we can only go back to releasing software when we are confident we have a healthy contribution lifecycle, via this contributor ladder. This means we need to spend time exercising, testing, and adjusting it before we feel confident enough to release it.”
This means there must be six consecutive community meetings with at least five members/reviewers/maintainers in attendance. We have continuous contributors joining our ladder, permanent reviewers elected and permanent maintainers elected.
That’s not going to happen overnight. de Carvalho expects this process could “take at least 6 months. Please, plan accordingly.”
ESO has reached a pivotal moment. Its future depends on the willingness of its user base and the broader Kubernetes community to keep one of the ecosystem’s most critical secrets-management tools alive by addressing this crisis.
It appears they’ll weather this storm. However, ESO is far from the only open source project facing a lack of support. Maintainer burnout is becoming an all too common problem. It must be addressed, or someday soon (and it won’t be long) we’ll see a vital but little-known open source project fall through the support cracks. Businesses will find themselves facing zero-day security problems without any warning or any clue on how to address them.
