Skip to content

Commit 7efee83

Browse files
aryan16aryan16
committed
add all mesh authz model
1 parent 78d0656 commit 7efee83

File tree

1 file changed

+146
-3
lines changed

1 file changed

+146
-3
lines changed

‎geps/gep-3779/index.md

Lines changed: 146 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -53,7 +53,7 @@ An identity-based authorization API is essential because it provides a structure
5353
| Aspect | Istio | Linkerd | Cilium |
5454
| ----- | ----- | ----- | ----- |
5555
| **Policy CRDs** | `AuthorizationPolicy` (APIs `security.istio.io/v1`) | `AuthorizationPolicy` (CRD `policy.linkerd.io/v1alpha1`), plus supporting CRDs (`Server`, `HTTPRoute`, `MeshTLSAuthentication`) | `CiliumNetworkPolicy` and `CiliumClusterwideNetworkPolicy` (superset of K8s NetworkPolicy) |
56-
| **Identity model** | Identities derived from mTLS peer certificates (bound to SA): <ul><li>SPIFFE-like principal `<trust-domain>/ns/<namespace>/sa/<serviceaccount>`. </li> <li>ServiceAccount name </li> <li>Namespaces</li></ul></br> identity within JWT derived from `request.auth.principal`<br/><br/>IPBlocks and x-forwarded-for ipBlocks | Identities derived from mTLS peer certificates (bound to SA trust domain `identity.linkerd.cluster.local`. Policies reference service accounts or explicit mesh identities (e.g. `webapp.identity.linkerd.cluster.local`). <br/><br/>Policies use `requiredAuthenticationRefs` to reference the entities who get authorization. This is a list of targetRefs and it can include: <ul><li>ServiceAccounts</li> <li>`MeshTLSAuthentication` - which represents a set of mesh identities either with a mesh identities strings or reference to serviceAccounts</li> <li>`NetworkAuthentication` - represents sets of IPs or subnets.</li></ul> |Cilium service mesh can leverage SPIFFE identities in certs that are used for handshake. These SPIFFEE identities are mapped to CiliumIdentities. You can read more about cilium identities in [CiliumIdentity](#CiliumIdentity). <br/><br/>Policies only target abstractions like label selectors, node selectors, CIDR blocks and Cilium predefined [entities](https://docs.cilium.io/en/stable/security/policy/language/#entities-based).|
56+
| **Identity model** | Identities derived from mTLS peer certificates (bound to SA): <ul><li>SPIFFE-like principal `<trust-domain>/ns/<namespace>/sa/<serviceaccount>`. </li> <li>ServiceAccount name </li> <li>Namespaces</li></ul></br> identity within JWT derived from `request.auth.principal`<br/><br/>IPBlocks and x-forwarded-for ipBlocks | Identities derived from mTLS peer certificates (bound to SA trust domain `identity.linkerd.cluster.local`. Policies reference service accounts or explicit mesh identities (e.g. `webapp.identity.linkerd.cluster.local`). <br/><br/>Policies use `requiredAuthenticationRefs` to reference the entities who get authorization. This is a list of targetRefs and it can include: <ul><li>ServiceAccounts</li> <li>`MeshTLSAuthentication` - which represents a set of mesh identities either with a mesh identities strings or reference to serviceAccounts</li> <li>`NetworkAuthentication` - represents sets of IPs or subnets.</li></ul> |Cilium service mesh can leverage SPIFFE identities in certs that are used for handshake. These SPIFFEE identities are mapped to CiliumIdentities. You can read more about cilium identities in [CiliumIdentity](#CiliumIdentity). <br/><br/>Policies target abstractions like service accounts in the form of labels, pod labels, namespace label, node selectors, CIDR blocks and Cilium predefined [entities](https://docs.cilium.io/en/stable/security/policy/language/#entities-based).|
5757
| **Enforcement** | For Istio with sidecars - a proxy on each pod. For ambient, ztunnel node agent enforces mTLS based L4 authorization, L7 authorization is being enforced in waypoints if any. <br/><br/> Istio supports ALLOW, DENY, CUSTOM (often used for external authorization), and AUDIT. DENY policies in istio's context are used to enforce higher priority deny policies. The allow semantics is that whatever is not allowed explicitly (and assuming there is any policy for the same match) is implicitly denied | Linkerd data-plane proxy (injected into each pod). The proxy enforces policies via mTLS identity checks. <br/><br/> Linkerd supports AUDIT and ALLOW. There is not DENY policies, whats not allowed (and assuming there is any policy for the same match) is implicitly denied. | For L3/4 Ingress Rules, CiliumNetworkPolicy enforcement - an eBPF-based datapath in the Linux kernel on the destination node. If L7 http rules are specified, the packet is redirected for a node-local envoy for further enforcement.<br/><br/>Cilium service mesh also offers a kind of AuthN where a Cilium agent on the src node, is talking to another agent on the destination node, using the pod’s spiffee identities.|
5858
| **Request Match criteria** | Policies can target a group of pods using label selector, a Gateway/Service (this means targeting a waypoint proxy) or a GatewayClass - meaning all the gateways created from this class. Policies without a label selector in a namespace implies the whole namespace is targeted. <br/><br/> Fine-grained L7 and L4 matching: HTTP/gRPC methods, paths, headers, ports, SNI, etc.Policies use logical OR over rules. <br/><br/>All match criterias are inline in the policy. See https://istio.io/latest/docs/reference/config/security/authorization-policy/#Rule-To and https://istio.io/latest/docs/reference/config/security/authorization-policy/#Rule-when | Policies can target: <ul><li>A `Server` which describes a set of pods (using fancy label match expressions), and a single port on those pods.</li> <li>A user can optionally restrict the authorization to a smaller subset of the traffic by targeting an HTTPRoute. (TODO: any plans to support sectionNames?)</li> <li> A namespace - this indicates that the policy applies to all traffic to all Servers and HTTPRoutes defined in the namespace.</li></ul> Note: We leave `ServerAuthorization` outside the scope as it planned to be deprecated (per linkerd website) | Policies can target groups of pods using label selector (`endpointSelector`), or by node-labels (`nodeSelector`). Cilium supports L7 via built-in HTTP parsing: rules can match HTTP methods, paths, Kafka, etc. For example, a CiliumNetworkPolicy can allow only specific HTTP methods/paths on a port. |
5959
| **Default policies and admin policies** | If **no** ALLOW policy matches, traffic is **allowed** by default. You can deploy an overridable - default deny by default by deploying an **allow-nothing** policy in either the namespace or istio-system <br/><br/>AuthorizationPolicies in the `istio-system` namespace apply to the whole mesh and take precedence. These are not overridable by namespace-level policies. | Default inbound policy can be set at install time using `proxy.defaultInboundPolicy`. Supported values are: <ul><li>`all-unauthenticated:` allow all traffic. This is the default.</li> <li>`all-authenticated:` allow traffic from meshed clients in the same or from a different cluster (with multi-cluster).</li> <li>`cluster-authenticated:` allow traffic from meshed clients in the same cluster.</li> <li>`cluster-unauthenticated:` allow traffic from both meshed and non-meshed clients in the same cluster.</li> <li>`deny:` all traffic are denied. </li> <li>`audit:` Same as all-unauthenticated but requests get flagged in logs and metrics.</li> </ul> <br/>Users can override the default policies for namespaces/pods or by setting the [config.linkerd.io/default-inbound-policy](http://config.linkerd.io/default-inbound-policy) annotation There is no support for admin, non overridable policies. | Follows Kubernetes NetworkPolicy semantics by default: if no `CiliumNetworkPolicy` allows the traffic, it is allowed (no implicit deny). Operators must apply explicit deny rules or “default-deny” policies to block traffic. <br/><br/> `CiliumClusterwideNetworkPolicy` exists for admin enforcement.)|
@@ -64,13 +64,127 @@ Every mesh vendor has their own API of such authorization. Below we describe the
6464
#### Istio
6565
Link: [Istio authorization policy docs](https://istio.io/latest/docs/reference/config/security/authorization-policy/)
6666

67-
TODO
67+
Istio's AuthorizationPolicy can enforce access control by specifying allowed identities using the `source.principals` field, which matches authenticated service account identities via mTLS.
68+
69+
```
70+
apiVersion: security.istio.io/v1beta1
71+
kind: AuthorizationPolicy
72+
metadata:
73+
name: allow-sleep
74+
namespace: default
75+
spec:
76+
selector:
77+
matchLabels:
78+
app: httpbin # The policy applies to pods with this label
79+
action: ALLOW
80+
rules:
81+
- from:
82+
- source:
83+
principals: ["cluster.local/ns/default/sa/sleep"]
84+
```
6885

6986
#### Linkerd
7087

7188
Link: [Linkerd authorization policy docs](https://linkerd.io/2-edge/reference/authorization-policy/)
7289

73-
TODO
90+
In Linkerd, identity-based authorization is enforced using AuthorizationPolicy and MeshTLSAuthentication, where MeshTLSAuthentication specifies allowed mTLS identities (e.g., sleep.default.serviceaccount.identity.linkerd.cluster.local), ensuring that only authenticated workloads can access a resource.
91+
92+
Linkerd Policy can by applied to two different targets.
93+
94+
##### Pod Labels with Server Resource
95+
96+
```
97+
apiVersion: policy.linkerd.io/v1beta1
98+
kind: Server
99+
metadata:
100+
namespace: default
101+
name: httpbin-server
102+
spec:
103+
podSelector:
104+
matchLabels:
105+
app: httpbin
106+
port: 8080
107+
proxyProtocol: HTTP/2
108+
109+
----
110+
apiVersion: policy.linkerd.io/v1beta1
111+
kind: MeshTLSAuthentication
112+
metadata:
113+
name: sleep-authn
114+
namespace: default
115+
spec:
116+
identities:
117+
- sleep.default.serviceaccount.identity.linkerd.cluster.local
118+
----
119+
120+
apiVersion: policy.linkerd.io/v1beta1
121+
kind: AuthorizationPolicy
122+
metadata:
123+
name: allow-sleep
124+
namespace: default
125+
spec:
126+
targetRef:
127+
group: policy.linkerd.io
128+
kind: Server
129+
name: httpbin-server
130+
requiredAuthenticationRefs:
131+
- name: sleep-authn
132+
kind: MeshTLSAuthentication
133+
group: policy.linkerd.io/v1beta1
134+
135+
---
136+
```
137+
138+
##### HTTPRoutes
139+
140+
```
141+
apiVersion: gateway.networking.k8s.io/v1
142+
kind: HTTPRoute
143+
metadata:
144+
name: httpbin-route
145+
namespace: default
146+
spec:
147+
parentRefs:
148+
- name: httpbin
149+
kind: Service
150+
rules:
151+
- matches:
152+
- path:
153+
type: PathPrefix
154+
value: /
155+
backendRefs:
156+
- name: httpbin
157+
port: 80
158+
159+
-----
160+
161+
apiVersion: policy.linkerd.io/v1beta1
162+
kind: MeshTLSAuthentication
163+
metadata:
164+
name: sleep-authn
165+
namespace: default
166+
spec:
167+
identities:
168+
- sleep.default.serviceaccount.identity.linkerd.cluster.local
169+
-----
170+
171+
apiVersion: policy.linkerd.io/v1beta1
172+
kind: AuthorizationPolicy
173+
metadata:
174+
name: allow-sleep-http
175+
namespace: default
176+
spec:
177+
targetRef:
178+
group: gateway.networking.k8s.io
179+
kind: HTTPRoute
180+
name: httpbin-route
181+
requiredAuthenticationRefs:
182+
- name: sleep-authn
183+
kind: MeshTLSAuthentication
184+
group: policy.linkerd.io/v1beta1
185+
---
186+
```
187+
74188

75189
#### Cilium
76190

@@ -79,6 +193,35 @@ Cilium has the concept of CiliumIdentity. Pods are assigned identities derived f
79193

80194
More on https://docs.cilium.io/en/stable/internals/security-identities/ & https://docs.cilium.io/en/stable/security/network/identity/
81195

196+
Cilium also automatically labels each pod with its associated service account using the label io.cilium.k8s.policy.serviceaccount. This label can be used in CiliumNetworkPolicy to enforce identity-based access controls
197+
198+
[ServiceAccounts Based Identities](https://docs.cilium.io/en/latest/security/policy/kubernetes/#serviceaccounts)
199+
200+
Following the CiliumNetworkPolicy for client identities.
201+
202+
```
203+
apiVersion: "cilium.io/v2"
204+
kind: CiliumNetworkPolicy
205+
metadata:
206+
name: "k8s-svc-account-policy"
207+
spec:
208+
endpointSelector:
209+
matchLabels:
210+
io.cilium.k8s.policy.serviceaccount: httpbin
211+
ingress:
212+
- fromEndpoints:
213+
- matchLabels:
214+
io.cilium.k8s.policy.serviceaccount: sleep
215+
toPorts:
216+
- ports:
217+
- port: '80'
218+
protocol: TCP
219+
rules:
220+
http:
221+
- method: GET
222+
path: "/"
223+
```
224+
82225

83226
## API
84227

0 commit comments

Comments
 (0)