|
| 1 | +# GEP-3779: Identity Based Authz for East-West Traffic |
| 2 | + |
| 3 | +* Issue: [#3779](https://github.com/kubernetes-sigs/gateway-api/issues/3779) |
| 4 | +* Status: Provisional |
| 5 | + |
| 6 | +(See [status definitions](../overview.md#gep-states).) |
| 7 | + |
| 8 | + |
| 9 | +## TLDR |
| 10 | + |
| 11 | +Provide a method for configuing **Gateway API implementations** to add identity based Authorization for east-west traffic. K8s Service Accounts can serve as the client identities. |
| 12 | + |
| 13 | + |
| 14 | +## Goals |
| 15 | + |
| 16 | +(Using the [Gateway API Personas](../../concepts/roles-and-personas.md)) |
| 17 | + |
| 18 | +* A way for Ana the Application Developer to configure a Gateway API implementation to perform identity based authorization that **allows** or **denies** the requests for some K8s clients to the K8s workloads. |
| 19 | + |
| 20 | +* A way for Chihiro, the Cluster Operator, to configure a Gateway API implementation to perform identity based authorization that **allows** or **denies** the requests from some K8s clients to all the K8s workload in some namespace. |
| 21 | + |
| 22 | +## Non-Goals |
| 23 | + |
| 24 | +* Supporting any other identity than K8s service accounts. |
| 25 | + |
| 26 | +* Supporting identity based authorization for north-south traffic. |
| 27 | + |
| 28 | + |
| 29 | +## Introduction |
| 30 | + |
| 31 | +An identity-based authorization API is essential because it provides a structured way to control access to network traffic based on client identities within a Kubernetes cluster, a capability particularly vital for enforcing fine-grained security policies in complex multi-tenant or large-scale environments. |
| 32 | + |
| 33 | +All the open source meshes have their own implementaition of idenity based authorization and it is now important use case for Gateway APIs for east-west traffic. |
| 34 | + |
| 35 | +### State of the World |
| 36 | + |
| 37 | +Here are the examples of some of the service meshes. |
| 38 | + |
| 39 | +* Istio |
| 40 | +Istio [authorization policy] (https://istio.io/latest/docs/reference/config/security/authorization-policy/) provides a way to validate the request based on client identities derived from peer certificate used in mTLS. Users can apply to Kubernetes pod labels. This same API is used in Istio's Ambient Mesh as well. |
| 41 | + |
| 42 | +* Linkerd |
| 43 | +Linkerd [authorization policy] (https://linkerd.io/2-edge/reference/authorization-policy/) also provides a way to validate the request based on client identities. Linkerd also provides an option to pick the peer identity from the client certs used in mTLS. |
| 44 | + |
| 45 | + |
| 46 | +With this GEP, we want to propose a new API that let users enable authorization based identities. The request to their data plane is then permitted or denied based on the rules defined in the authorization policy. |
| 47 | + |
| 48 | +Identity based authorization policies can also be applied to an entire namespace. The rules of that policy are enforced for network traffic involving all workloads within that namespace. |
| 49 | + |
| 50 | +## Outstanding Questions and Concerns (TODO) |
| 51 | + |
| 52 | + |
| 53 | +## API |
| 54 | + |
| 55 | + |
| 56 | + |
| 57 | +## Conformance Details |
| 58 | + |
| 59 | + |
| 60 | +#### Feature Names |
| 61 | + |
| 62 | + |
| 63 | +### Conformance tests |
| 64 | + |
| 65 | + |
| 66 | +## Alternatives |
| 67 | + |
| 68 | + |
| 69 | +## References |
0 commit comments