Skip to content

Commit 38ac13b

Browse files
committed
GEP 3779 - Identity Based Authz for east-west
1 parent fe41f50 commit 38ac13b

File tree

2 files changed

+88
-0
lines changed

2 files changed

+88
-0
lines changed

geps/gep-3779/index.md

Lines changed: 69 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,69 @@
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

geps/gep-3779/metadata.yaml

Lines changed: 19 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,19 @@
1+
apiVersion: internal.gateway.networking.k8s.io/v1alpha1
2+
kind: GEPDetails
3+
number: 3779
4+
name: Identity Based Authz for east-west traffic
5+
status: Provisional
6+
# Any authors who contribute to the GEP in any way should be listed here using
7+
# their GitHub handle.
8+
authors:
9+
- aryan16
10+
- liorliberman
11+
# references is a list of hyperlinks to relevant external references.
12+
# It's intended to be used for storing GitHub discussions, Google docs, etc.
13+
references: {}
14+
# featureNames is a list of the feature names introduced by the GEP, if there
15+
# are any. This will allow us to track which feature was introduced by which GEP.
16+
featureNames: {}
17+
# changelog is a list of hyperlinks to PRs that make changes to the GEP, in
18+
# ascending date order.
19+
changelog: {}

0 commit comments

Comments
 (0)