Skip to content

Native NGINX Configuration in Gateway API Design #1258

Closed
@mpstefan

Description

@mpstefan

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

Metadata

Metadata

Assignees

No one assigned

    Labels

    epicRepresents an epic. Contains sub-issuesrefinedRequirements are refined and the issue is ready to be implemented.

    Type

    No type

    Projects

    No projects

    Milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions