fix

Author: LiorLieberman

geps/gep-3779/index.md

@@ -57,7 +57,6 @@ An identity-based authorization API is essential because it provides a structure
 | **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. | TODO(liorlieberman) |
 | **Request Match criteria** | Fine-grained L7 and L4 matching: HTTP/gRPC methods, paths, headers, ports, SNI, etc., plus source identity (namespace, service account). 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](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](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)  | TODO(liorlieberamn) |
 | **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. | TODO(liorlieberman)|
-| **YAML Configuration** | Istio `AuthorizationPolicy` CRD. E.g., to **allow** a namespace or service-account to call a service: |  |  |
 
 
 Every mesh vendor has their own API of such authorization. Below we describe the UX for different implementations: