Kubernetes Dev,
Ingress NGINX is not the "official" Ingress Controller (there's none). There have been several evolutions during this project: dynamic backend configs when they’re not supported natively via NGINX (using Openresty), new modules, new balancing algorithms, and so on. We can't confirm but can say that probably Ingress NGINX is one of the richest feature ingresses.
And with new features, there are new bugs. One of the feelings we've got since we started maintaining Ingress is that usually, one or two users need a new feature, and they implement it (thanks for the PR!!), but when a bug happens, no one steps forward to fix it.
This lack of support becomes a burden to Ingress NGINX maintainers: we now have to split our time between issues, bug fixing, new feature reviews, and the bugs that may arise from this feature. We do this in our spare time, and it's becoming hard for us to keep this pace.
There is this feeling that we probably support too many features. Some (a lot) of them are external to NGINX, and this turns out to need a complex build process, with modules that are sometimes not supported anymore and our slowing down the core evolution.
The recent CVEs on Ingress NGINX are no one's fault or blame. But, fixing them the right way is hard now, as any piece we move can cause other problems (and CVEs). CVE-2021-25748, CVE-2021-25745, and CVE-2021-25746 to name a few prominent ones.
With this situation in place, we think (and decided) that it's time to temporarily pause accepting new features and focus on fixing and stabilizing Ingress NGINX. We understand that some people may need to merge a trivial new feature. Still, we are asking the community to understand that maintaining the project at this pace is becoming hard for the project maintainers. We understand that you waited too long with your PR in the queue, and we are sorry! But it's hard for us as well to keep the project stable.
Our current thinking is a six-month timeline with this feature freeze in place, we want to focus on the following efforts:
Properly fixing Ingress Class logics (and rectifying the current implementation)
Splitting control plane and data plane (that will help us in Gateway API efforts in the future as well)
Establishing a new features acceptance criteria
Review and deprecate existing but not many (or not trivial) features with a proper timeline.
These deprecations may include removing mod_security, opentracing, etc., and keeping the code simple!
Deprecate the legacy branch that still supports ingress v1beta1
Drop old Kubernetes versions from CI and keep the same supportability pace of Kubernetes versions (v -3)
Upgrade to the latest stable NGINX with reduced code footprint
Increase security footprint of Ingress-nginx with Openssf recommendations and tooling
Streamline release process
3 new labels in our issue tracker will be added to track the progress of the above work; area/stabilization, area/release, and area/security. We have also created a project to track this work as well, https://github.com/kubernetes/ingress-nginx/projects/52. If there is anything you think should be a part of this effort, please add the labels and projects so we can discuss them in our community calls.
For more information, we have discussed this in our project meeting (https://www.youtube.com/watch?v=gTnY2kPc3ZY)
Our community meeting is every Thursday at 11 am eastern, more info is in this doc SIG-Network Ingress NGINX Meeting
Slack Ingress-nginx-user channel https://kubernetes.slack.com/archives/CANQGM8BA
Please contact us via slack, community meetings, or this dev mailing list if you have any concerns.
Thank you,
Ingress-Nginx maintainers