Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

consider more api-defined behaviors #830

Open
ilrudie opened this issue Feb 27, 2024 · 0 comments
Open

consider more api-defined behaviors #830

ilrudie opened this issue Feb 27, 2024 · 0 comments
Labels
area/configurability Area: Configurability area/security Area: Security

Comments

@ilrudie
Copy link
Contributor

ilrudie commented Feb 27, 2024

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.

@ilrudie ilrudie added area/configurability Area: Configurability area/security Area: Security labels Feb 27, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/configurability Area: Configurability area/security Area: Security
Projects
None yet
Development

No branches or pull requests

1 participant