Description
As a cluster operator running NGF
I want an easy way to apply configuration, NGINX or otherwise, at various levels of my application architecture
So that I can set defaults that can be overridden by application developers and security policies that cannot.
As a application developer running NGF
I want an easy way to configure NGINX directives by route
So that I can own the NGINX configuration for my own applications.
Background
As we move to expose native NGINX configuration to our users, we need to design an extensible way for that configuration to be set. Looking at the current GEP for meta-resources and policies it appears the most likely answer is in our own set of policies so that our configuration could easily be applied to the GatewayClass, Gateway, or Route objects.
The goal of this epic is to do some up front design to determine where various NGINX directives could be applied, what groups they might belong to, and what policies will need to be defined in future. We also need to implement a policy that include otel tracing support. We need to achieve a sweet spot between groups of functionality that are specific enough without reaching a large number of total policies.
Acceptance Criteria
- A list of high-priority NGINX functionality that we want to deliver.
- The high-priority NGINX functionality is formed into groups and those groups are associated with one or more roles from Gateway API.
- For each group, extension or attachment points for implementation are identified.
### Tasks
- [ ] https://github.com/nginxinc/nginx-gateway-fabric/issues/1410
- [ ] https://github.com/nginxinc/nginx-gateway-fabric/issues/1259
- [ ] https://github.com/nginxinc/nginx-gateway-fabric/issues/1411
- [ ] https://github.com/nginxinc/nginx-gateway-fabric/issues/1603