You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Presently ztunnel has some routing and policy behaviors that are expressed in rust rather than through an API. This does help keep our config light and streamlined but also creates branching logic where bugs could hide. One example would be adding a waypoint which kicks in bits of rust logic which enforce policy that isn't explicitly defined in our policy API as well as allowing bypass of the normal policy enforcement under the assumption that it was the waypoints' prerogative to assert policy.
We could consider treating to/from-wapoint traffic normally and using auto-generated policy to express things like "this traffic requires waypoint traversal". This would introduce complexity in the control-plane which is going to have to create/configure policy that would presently be "free" since it's compiled into the ztunnel today.
There is also opportunity to try expressing routing to waypoint more generally. This may be the start of a slippery slope towards "general purpose" L4 proxy which is undesirable.
I think these two things can be implemented independently but are conceptually under a similar umbrella. It is conceivable to me that "traffic is traffic" for policy purposes achieves a desirable outcome which is worth the impl costs but a more general routing api is not for instance.
The text was updated successfully, but these errors were encountered:
Presently ztunnel has some routing and policy behaviors that are expressed in rust rather than through an API. This does help keep our config light and streamlined but also creates branching logic where bugs could hide. One example would be adding a waypoint which kicks in bits of rust logic which enforce policy that isn't explicitly defined in our policy API as well as allowing bypass of the normal policy enforcement under the assumption that it was the waypoints' prerogative to assert policy.
We could consider treating to/from-wapoint traffic normally and using auto-generated policy to express things like "this traffic requires waypoint traversal". This would introduce complexity in the control-plane which is going to have to create/configure policy that would presently be "free" since it's compiled into the ztunnel today.
There is also opportunity to try expressing routing to waypoint more generally. This may be the start of a slippery slope towards "general purpose" L4 proxy which is undesirable.
I think these two things can be implemented independently but are conceptually under a similar umbrella. It is conceivable to me that "traffic is traffic" for policy purposes achieves a desirable outcome which is worth the impl costs but a more general routing api is not for instance.
The text was updated successfully, but these errors were encountered: