Feature Request: Filter/route ingress traffic based on downstream service

[igreg]

Tell us about your request
Provide a way to control which VirtualNodes can access a service.

Which integration(s) is this request for?
All, I think.

Tell us about the problem you're trying to solve. What are you trying to do, and why is it hard?
We are trying to find a way to limit or control what virtual nodes can communicate to, within the Mesh network. Currently, it is only possible to explicitly define the backends services of a virtual node. We would like to be able to define the frontends nodes of a virtual service.

Are you currently working around this issue?
We haven't found an alternative/workaround yet. One possible way to achieve this would be to use a virtual router that matches specific headers in the request (e.g. using the header x-envoy-downstream-service-node) but AppMesh does not seem to inject any header that would allow us to route requests based on the identity of the downstream service.

Additional context
I had a look at TLS & IAM Role authorisation but not of those seem to be able to prevent or limit a node from communicating with a virtual service.

[andyfase]

Just to add a use-case for this.

Virtual Services/Nodes are likely to be owned by different teams. Each team is likely going to own the Virtual Service and Node configuration (locked down with IAM such that only that team can update the configuration for it).

In such a scenario it is very likely teams will want to "onboard" other virtual services (owned by other teams) to be allowed to consume their service, effectively white listed. Thus there is a need to whitelist clients or "frontend" services than can consume a given virtual service and the virtual nodes that make up that service.

This would hook into rate limiting nicely, where a service in the mesh (client) could be configured to have access at a given req/s rate.

[bcelenza]

Yup, this all makes sense to me.

When you think about filtering / authorizing ingress traffic, a few questions come to mind:

1. If your applications had a formal identity (a client certificate, JWT, etc.), would authorization based on that identity be sufficient to solve this? Are you looking for additional protection at the network level (i.e. security groups)?
2. I think there's an assumption on our part that, in the scenario described above, you wouldn't know what specific Virtual Nodes are attempting to access the Virtual Service -- it seems we need a higher level abstraction that encompasses a client identity that virtual nodes can be "attached" to. Does that resonate with this use case?

I think there are certainly tie-ins to #34 and #81 (and of course, #107), but I'd like to understand if we should be building something more so you don't need to think about what identity solution you're using within the mesh.

[dastbe]

While I think @bcelenza hit filter/authz scenario, I'm v curious about the routing story! My questions are

• When you say routing, are you focused on route visibility (only some services can access /admin) or target selection (identity A gets routed to destination 1, while B gets routed to destination 2), or both?
• For either of the above, how early would you want us to leverage that in configuration distribution? For example, if you specified that a route only applied to a certain identity (or identities), would you want us to only distribute that route to the nodes it pertained to?

[igreg]

@dastbe
I think particular context which focuses on security and managing boundaries between services integrated with AppMesh, we focus on route visibility. Maybe a better choice of words would be permitting traffic than routing. This could fit in nicely within the concept of Virtual routers though hence why the term router was used.

As for the implementation of this feature and your second question, would it be possible to filter ingress traffic at the receiving end rather than limit the distribution of routes to permitted nodes only? Both implementations would work but when troubleshooting configuration issues, the absence of routes in the configuration is harder to troubleshoot than an explicit set of filters in the configuration of the ingress envoy proxy.

@bcelenza

1. For us, a formal identity would be sufficient to filter traffic from downstream services. If network boundaries are needed, they can always be implemented via security groups in addition and aside of Appmesh.
2. In our case, my team was considering Virtual Nodes could be known by Virtual Services and used as a formal identity but I think you're right; an abstraction might be a useful improvement. In fact, would it be possible to leverage the RBAC filter in Envoy?