docs: add provisional GEP for Gateway API Firewall Support

[shaneutt]

What type of PR is this?
/kind gep

What this PR does / why we need it:

This takes the first provisional step of proposing firewall support for Gateway API, which has been very popular as per engagement in #3614.

Which issue(s) this PR fixes:

This supports, but does not resolve #3614.

Does this PR introduce a user-facing change?:

NONE

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: shaneutt

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• geps/OWNERS [shaneutt]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[rikatz]

/assign

[howardjohn]

I am concerned about the ability to actually fulfill the goals in this GEP. Just from reading the title, I was worried about running into the lowest-common-denominator problem: that there is almost no overlap between each firewall configuration surface, so we end up with an API that is not useful (or, we end up debating the API surface indefinitely).

Gateway API actually does already have a solution for this, with policy attachment. I suspect you may disagree, but when we are faced with a problem set that doesn't have much overlap, policy attachment of implementation specific policies is a much better experience for users than attempting to make an API that doesn't work.

After reading the GEP, my concerns are far greater, though. This set of goals is impossible to reasonable tackle. While the title if "Firewall", in typical products the feature set here actually spans 3-4 API surfaces: WAF, Authorization (typically separate from WAF!!), rate limiting, auditing, DLP. And I saw in the AI WG, LLM guardrails was also something of interest as part of this effort (which, again, differs from traditional WAF). I am very worried we are biting off way to much work with this effort and it will make it impossible to proceed.

Just as an anecdote, even just rate limiting is ridiculously complex to design an API around. I suspect it would be harder than BackendTLSPolicy was...

[shaneutt]

I am concerned about the ability to actually fulfill the goals in this GEP. Just from reading the title, I was worried about running into the lowest-common-denominator problem: that there is almost no overlap between each firewall configuration surface, so we end up with an API that is not useful (or, we end up debating the API surface indefinitely).

I am anticipating that we wont actually try to add significant API surface for this, see this conversation for some context.

In any case, I'm open to the possibility that this GEP moves to Withdrawn if we can't find the right stakeholders, and common surface.

Gateway API actually does already have a solution for this, with policy attachment. I suspect you may disagree, but when we are faced with a problem set that doesn't have much overlap, policy attachment of implementation specific policies is a much better experience for users than attempting to make an API that doesn't work.

This is getting into the "How?" we do things, which we're not ready for yet.

After reading the GEP, my concerns are far greater, though. This set of goals is impossible to reasonable tackle. While the title if "Firewall", in typical products the feature set here actually spans 3-4 API surfaces: WAF, Authorization (typically separate from WAF!!), rate limiting, auditing, DLP. And I saw in the AI WG, LLM guardrails was also something of interest as part of this effort (which, again, differs from traditional WAF). I am very worried we are biting off way to much work with this effort and it will make it impossible to proceed.

I will make sure you are considered a stakeholder for reviews, and that your concerns are incorporated 👍

Just as an anecdote, even just rate limiting is ridiculously complex to design an API around. I suspect it would be harder than BackendTLSPolicy was...

Agreed.

This is getting into the "How?", which we will get stuck on if we discuss this now. The important thing for this iteration is to align on the motivation and goals at a high level. If we do that, and then we move to the implementation details and we simply can not produce something that's effective within a reasonable scope, and is supported by multiple stakeholders, it is OK to consider this Withdrawn and keep it for posterity so that the community knows we looked into it, and what our reasons were for not continuing.

[mikemorris]

I am anticipating that we wont actually try to add significant API surface for this

In this case, I'm also wondering how this provides value that is not already available through HTTPRoute extensionRef custom filters or policy attachment, or what is missing from the current extension points to support this use case?

Something like first-class support for OWASP CRS configuration rules to provide WAF functionality in Gateway API might feel contentious and a scope stretch, but would at least feel more aligned with standardizing functionality within the Gateway API specification.

This does feel like it could be a valuable proprietary feature or product positioning for a Gateway API implementation, but I don't really see a purpose-built extension point enabling this as appropriate for the spec, when existing generic extension points may be sufficient (and potentially support the same or related use cases, such as using WASM modules to mutate or drop requests or responses as @jcchavezs mentioned in #4148 (comment)).

[shaneutt]

In this case, I'm also wondering how this provides value that is not already available through HTTPRoute
extensionRef custom filters

Filters could be viable, we need to decide. This is an important part of the exercise of this GEP. There could be challenges. One challenge is the should language around the order of processing filters, which is not conducive to security systems.

or policy attachment

Policy Attachment could be viable, we need to decide. This too is an important part of the exercise. There will be challenges, as it comes with many caveats. Ordering policies is one thing that can be challenging to get right, among others.

---

We are into implementation details however.

I want to be extra clear that if we get to the "How?" and there is no consensus, I am not shy about slapping a Withdrawn on it and providing a written explanation as to why. That way people who are looking at least know that we've tried, what we've tried, and what the difficulties are.

If possible however, the bare minimum I would like for this effort to result in a memorandum that provides some guidance to implementations that want to integrate firewalls with their Gateways, as I see this as a pretty common desire from users.

[shaneutt]

An explicit note about the potential to not change any API specification at all has been added in b195370. Please let me know if this seems reasonable for the purposes of moving forward with the initial PR, or if you have further concerns.

[robscott]

My concern here is that we probably shouldn't merge something this as provisional unless we can think of one or more plausible ways that we could implement it in Gateway API. While I agree that we should generally focus on user stories first to ensure we get to the right implementation details, I also want to ensure that we have a viable path forward before we go too far here.

I think this is a good discussion to have, I just think the better outcome here might be to have a page/doc somewhere where we list common categories of Gateway API extensions such as firewalls, and describe why we don't think they're in scope for Gateway API at the current point in time, potentially with link(s) to discussion(s) with more context. If we have a GEP for each instance like this, I think we could get pretty quickly overloaded with GEPs.

[shaneutt]

My concern here is that we probably shouldn't merge something this as provisional unless we can think of one or more plausible ways that we could implement it in Gateway API. While I agree that we should generally focus on user stories first to ensure we get to the right implementation details, I also want to ensure that we have a viable path forward before we go too far here.

I'm not sure why this is a concern: we've made it clear that one could use policy attachment, or possibly filters at a bare minimum. There's seems to be precedent in that cloud providers like GKE do this today.

I think this is a good discussion to have, I just think the better outcome here might be to have a page/doc somewhere where we list common categories of Gateway API extensions such as firewalls, and describe why we don't think they're in scope for Gateway API at the current point in time, potentially with link(s) to discussion(s) with more context.

I suppose that could be an outcome but it feels pretty arbitrary considering there's already implementations out there doing this (e.g. GKE).

If we have a GEP for each instance like this, I think we could get pretty quickly overloaded with GEPs.

If limiting the number of GEPs we have as a project becomes a common goal, we should find a neutral mechanism to start and not apply it in a procrustean manner to a mid-flight effort.

[mikemorris]

Taking this back to specifics, I'm seeing:

One challenge is the should language around the order of processing filters, which is not conducive to security systems.
Ordering policies is one thing that can be challenging to get right, among others.

Which reads to me as ordering is a core missing capability for our extension points. FWIW I don't particularly like the semantics for priority ordering over in AdminNetworkPolicy (it generally feels too complicated and easy to footgun or create conflicting/undefined states), but I'd be more open to a GEP introducing optional ordering functionality for those features, citing specific firewall behavior expectations as a user story requiring it, than what feels like an overly-broad product story GEP potentially spanning many disparate features (on the scale of GAMMA or WG AI Gateway from my perspective).

(I'm not concerned with "too many GEPs" FWIW, but I do want to try to constrain the focus to concrete enhancements rather than biting off too big a scope without the intent of actually bringing the solution into the spec.)

[shaneutt]

Which reads to me as ordering is a core missing capability for our extension points.

Yes.

FWIW I don't particularly like the semantics for priority ordering over in AdminNetworkPolicy (it generally feels too complicated and easy to footgun or create conflicting/undefined states), but I'd be more open to a GEP introducing optional ordering functionality for those features, citing specific firewall behavior expectations as a user story requiring it, than what feels like an overly-broad product story GEP potentially spanning many disparate features (on the scale of GAMMA or WG AI Gateway from my perspective).

I had a similar thought. Not sure it's only this, but this does seem like an area to focus. Since we seem to agree on that, I have added that to the notes for follow-up.

(I'm not concerned with "too many GEPs" FWIW, but I do want to try to constrain the focus to concrete enhancements rather than biting off too big a scope without the intent of actually bringing the solution into the spec.)

👍

[robscott]

Thanks for starting this conversation @shaneutt! I know in the past @youngnick voiced significant concerns about moving forward with something like this, so let's make sure he has time to respond when he gets back before we get too far with this.

/hold

[robscott]

My concern here is that we probably shouldn't merge something this as provisional unless we can think of one or more plausible ways that we could implement it in Gateway API. While I agree that we should generally focus on user stories first to ensure we get to the right implementation details, I also want to ensure that we have a viable path forward before we go too far here.

I think this is a good discussion to have, I just think the better outcome here might be to have a page/doc somewhere where we list common categories of Gateway API extensions such as firewalls, and describe why we don't think they're in scope for Gateway API at the current point in time, potentially with link(s) to discussion(s) with more context. If we have a GEP for each instance like this, I think we could get pretty quickly overloaded with GEPs.