-
Notifications
You must be signed in to change notification settings - Fork 1.5k
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Signed-off-by: Ian Rudie <[email protected]>
- Loading branch information
Showing
1 changed file
with
34 additions
and
0 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,34 @@ | ||
--- | ||
title: Policy enforcement in ambient mode | ||
description: The two enforcement points for policy in an ambient mesh. | ||
weight: 20 | ||
owner: istio/wg-networking-maintainers | ||
test: no | ||
--- | ||
|
||
Istio's ambient data plane splits the data plane into two different sets of components. This architecture allows users to only pay for application layer processing if they need it. The trade off made is the extra complexity of understanding how traffic flows through this architecture and where policy will be enforced. This guide will introduce a number of broad scenarios and explore the permutations therein and the details to understand for each scenario. | ||
|
||
## TCP Enforcement | ||
|
||
In the simplest enforcement scenario you simply want to enforce policy against TCP attributes and you have no waypoint proxies in your traffic's path. These policies can be enforced by the ztunnel proxies. | ||
|
||
Once you introduce a waypoint proxy the ideal place to enforce policy shifts. Traffic arriving at the destination ztunnel will be coming from the waypoint's identity because waypoint proxies do not impersonate src identity on behalf of the client. This means that even if you only wish to enforce policy against TCP attributes you should bind that policy to your waypoint proxy. A futher TCP policy may be applied to your workload to request that ztunnel enforce things like, "in-mesh traffic needs to come from my waypoint in order to reach my application". This type of policy allows you to choose if "bypassing" the waypoint proxy is permissable in your scenario. | ||
|
||
// link to details? table? further clarification | ||
|
||
## HTTP Enforcement | ||
|
||
In a scenario where policy requires application layer aware attributes, such as HTTP verbs, a waypoint proxy is required. | ||
|
||
// details | ||
|
||
## Ingress and Policy Enforcement | ||
|
||
If your application is exposed outside the cluster via and Istio ingress gateway there are additional considerations to be aware of expecially concerning enforcement of TCP layer policy in ztunnel | ||
|
||
// details | ||
|
||
## Deny Policy | ||
|
||
// details | ||
|