|
| 1 | +# GEP-3614: Firewall |
| 2 | + |
| 3 | +* Issue: [#3614](https://github.com/kubernetes-sigs/gateway-api/issues/3614) |
| 4 | +* Status: Provisional |
| 5 | + |
| 6 | +## TLDR |
| 7 | + |
| 8 | +The ability to attach firewall rules for ingress L3, L4 and L7 Gateway traffic. |
| 9 | + |
| 10 | +## Motivation |
| 11 | + |
| 12 | +`Gateways` are commonly exposed to the internet, which puts them as risk of |
| 13 | +attack. Internal networks can become compromised as well. We should provide |
| 14 | +tooling, documentation and best-practices for users to restrict and control |
| 15 | +access to their `Gateways`. |
| 16 | + |
| 17 | +### User Stories |
| 18 | + |
| 19 | +* As an application developer, I want to allow specific IPs to access my |
| 20 | + application. |
| 21 | +* As an application developer, I want all ingress traffic for my Gateways to be |
| 22 | + restricted to my CDN. |
| 23 | +* As an application developer, I want to block all requests from specific user |
| 24 | + agents OR only allow specific user agents. |
| 25 | +* As a gateway operator I want to be able to identify and block malformed HTTP |
| 26 | + requests before they reach backend applications. |
| 27 | +* As a gateway operator I want to filter/sanitize requests to block XSS attacks |
| 28 | + before they reach my backend applications. |
| 29 | +* As a gateway operator I want to attach complete rulesets maintained by |
| 30 | + upstream standards bodies to block well known common threats and dynamically |
| 31 | + update for new threats over time. |
| 32 | +* As a cluster operator I want to be able to block traffic to gateways from |
| 33 | + specific geographical regions, or only allow specific regions. |
| 34 | + |
| 35 | +## Goals |
| 36 | + |
| 37 | +* Enable attaching firewall engines to a `Gateway` |
| 38 | +* Enable `Gateway`-level firewall rule enforcement |
| 39 | +* Enable `HTTPRoute`-level firewall rule enforcement |
| 40 | +* Enable simple IP allow/deny lists |
| 41 | +* Provide documentation and best practices for implementations which describe |
| 42 | + how firewall engines and rules can best be integrated into a Gateway API |
| 43 | + implementation. |
| 44 | + |
| 45 | +## Non-Goals |
| 46 | + |
| 47 | +* Building a firewall implementation |
| 48 | +* Mesh-level support |
| 49 | + |
| 50 | +## API |
| 51 | + |
| 52 | +**TODO**: First PR will not include any implementation details, in favor of |
| 53 | +building consensus on the motivation, goals and non-goals first. _"How?"_ we |
| 54 | +implement shall be left open-ended until _"What?"_ and _"Why?"_ are solid. |
| 55 | + |
| 56 | +## Alternatives Considered |
| 57 | + |
| 58 | +### NetworkPolicy |
| 59 | + |
| 60 | +When discussing this originally the obvious question whether `NetworkPolicy` |
| 61 | +is sufficient, or should have some role in this, was asked. We do not consider |
| 62 | +it sufficient to resolve the goals unto itself. For the purposes of this GEP, |
| 63 | +we consider `NetworkPolicy` as an implementation detail at most: implementations |
| 64 | +_may_ choose how they enforce firewall rules, whether some of that is |
| 65 | +implemented with `NetworkPolicy` under the hood or not is up to them. |
| 66 | + |
| 67 | +## References |
| 68 | + |
| 69 | +* [GEP-1767: CORS](https://github.com/kubernetes-sigs/gateway-api/issues/1767) |
| 70 | + |
0 commit comments