Open rikatz opened 1 month ago
This issue is currently awaiting triage.
If Ingress contributors determines this is a relevant issue, they will accept it by applying the triage/accepted
label and provide further guidance.
The triage/accepted
label can be added by org members by writing /triage accepted
in a comment.
The ability to add custom configuration to nginx is a feature for me, and I cannot realistically see it replaced by annotations or even the gateway API. We're making extensive use of maps, custom rate limits and rewrites, for example.
The potential for a "security risk" lies entirely with the operator running the controller, with snippet annotations already being turned off by default now. There is no risk to the project itself and I'm not happy to just hand wave a "you have been warned" feature away because someone could potentially misconfigure something.
We rely heavily on the current snippet annotations to handle rewrites, static reverse proxying of subpaths, header manipulation, etc. on a large set of dynamic domains (virtual hosts). An alternative way to accomplish these use cases would be necessary.
Ingress NGINX has 130 annotations, and still some of the required features are not implemented.
The workaround to expose more of the NGINX functionality to users was to allow snippet annotations, which in fact allows users to add their own configuration to nginx.conf.
The problem is that these kind of annotation allow users to add random and dangerous configurations and present a security risk for the project.
This way, I propose that we deprecate and remove snippet annotations and configuration from Ingress NGINX and future features should be analyzed and implemented via proper annotations or only if supported on the Gateway API annotations
/kind deprecation