service addressed waypoint #832
Conversation
Signed-off-by: ilrudie <ian.rudie@solo.io>
Signed-off-by: ilrudie <ian.rudie@solo.io>
Signed-off-by: ilrudie <ian.rudie@solo.io>
istio-testing
added
do-not-merge/work-in-progress
src/proxy/outbound.rs
Outdated
| SocketAddr::new(waypoint_ip, waypoint_us.port); | ||
| let destination_service = ServiceDescription::try_from(&*s).ok(); | ||
|
|
||
| return Ok(Request { |
There was a problem hiding this comment.
can we abstract a fine grained function to reuse
There was a problem hiding this comment.
Do you mean some sort of "request builder" instead of returning literals all the time?
There was a problem hiding this comment.
I'd rather not address in this PR if it's all the same. I opened #846 to track work on this idea.
Signed-off-by: ilrudie <ian.rudie@solo.io>
ilrudie
force-pushed
the
svc-addressed-waypoint
branch
from
4452e3f
to
7a53961
Compare
|
This seems far enough along to begin work on CP. If folks feel strongly we should finish this out now I'm happy to do so but otherwise I think it may make more sense to put a pin in this for a moment and begin work on istiod so both PRs can merge closer together. |
Signed-off-by: ilrudie <ian.rudie@solo.io>
ilrudie
force-pushed
the
svc-addressed-waypoint
branch
from
7a53961
to
e8abd62
Compare
src/proxy/outbound.rs
Outdated
|
|
||
| return Ok(Request { | ||
| protocol: Protocol::HBONE, | ||
| direction: Direction::Inbound, |
There was a problem hiding this comment.
probably should be. I did a copy/paste to start building the request and it seems to be a hangover from a hangover.
|
How are we preventing bypass on the inbound side? Currently only Workload's waypoints are guarded on the inbound side. This can be handled with the control plane:
|
|
This thread affects the decision for the bypass stuff... which waypoint must we traverse. |
|
Option 4 (or maybe 2.1) expose some API for the control plane to optionally create policy at the svc owner's discretion |
Signed-off-by: Ian Rudie <ian.rudie@solo.io>
istio-testing
removed
the
do-not-merge/work-in-progress
|
How can we skip sending to waypoint if a pod belongs to svc disabled waypoint according to https://docs.google.com/document/d/1DAM_6SajCyC2hD8wBUraaZWZJqUVYPyemzw0-xpHmdY/edit?disco=AAABIl-P1-k |
I think your question is what if a user declares they want a waypoint on a pod and declares they want #none for svc. It's an interesting case and I'm not sure the answer is clear here. Should #none on a service mean bypass all waypoints for to service traffic or just do not configure a namespace-defined waypoint? cc @louiscryan and @stevenctl |
Use-waypoint is a directive around how to route 'addressed' traffic so we should not infer anything from "service X capture #none" other than that the user wants traffic addressing that service (via VIP/host) to not transit a waypoint. The user can simultaneously say that they want traffic addressing a pod which is a member of that service to go through a waypoint. There is no conflict here, its just important to document for users the semantics of capture on the addressing mechanism. If users want to remove ambiguity they should just capture namespaces for the most part. |
implementation for sending to waypoint for service-addressed traffic