This example shows routing decisions made on the basis of what user is logged in. Most users accessing the bookinfo app see reviews from reviews:v1, while authenticated user "jason" sees reviews from reviews:v2.
I know what is really being demonstrated here is the ability to route traffic based on headers. Cookies, like the user cookie, after all, are sent from client to server in an HTTP request header.
However, most readers probably walk away from this example with a different takeaway-- "Istio lets me route different users to different endpoints." This is obviously a valuable idea. Imagine that during a blue/green deployment, for instance, you might want your product owner to get into the new version first to do some UAT before you start using weights to shift traffic from everyone else over.
The problem is that this notion of "Istio lets me route different users to different endpoints" doesn't hold up in the real world.
The bookinfo app is a toy. The current user's username is stored in plain text in a cookie that can be edited, allowing an attacker to assume the identity of another user. Apps in the real world do not work this way. Any cookie that plays a role in user identity / session is either going to be encrypted or might even be an opaque token that is correlated to identity or session on the server side. Obviously, this is to prevent identity / session hijacking.
My point is only that the "jason" example sets readers up with a false notion that Istio can be used in this desirable way in the real world, when really, it cannot. Is there, perhaps, a less misleading demonstration of routing requests based on a header that could replace this example?
This example shows routing decisions made on the basis of what user is logged in. Most users accessing the bookinfo app see reviews from reviews:v1, while authenticated user "jason" sees reviews from reviews:v2.
I know what is really being demonstrated here is the ability to route traffic based on headers. Cookies, like the
usercookie, after all, are sent from client to server in an HTTP request header.However, most readers probably walk away from this example with a different takeaway-- "Istio lets me route different users to different endpoints." This is obviously a valuable idea. Imagine that during a blue/green deployment, for instance, you might want your product owner to get into the new version first to do some UAT before you start using weights to shift traffic from everyone else over.
The problem is that this notion of "Istio lets me route different users to different endpoints" doesn't hold up in the real world.
The bookinfo app is a toy. The current user's username is stored in plain text in a cookie that can be edited, allowing an attacker to assume the identity of another user. Apps in the real world do not work this way. Any cookie that plays a role in user identity / session is either going to be encrypted or might even be an opaque token that is correlated to identity or session on the server side. Obviously, this is to prevent identity / session hijacking.
My point is only that the "jason" example sets readers up with a false notion that Istio can be used in this desirable way in the real world, when really, it cannot. Is there, perhaps, a less misleading demonstration of routing requests based on a header that could replace this example?