Hi Zach,
Let me start over. I, and I'm sure many others, were excited by the completion of story
https://www.pivotaltracker.com/n/projects/966314/stories/82311924 This enables applications with their own service discovery mechanisms to bypass the routers and work in a cloud foundry deployment. However, as Dieu called out to enable this type of app you'd have to open security groups to allow direct access to DEAs and warden port ranges for these apps. Today opening up direct access to DEA ports is not a big deal because there is little functional difference between hitting an app instance directly and hitting it through the router.
However, with the concept of Route Services this changes. For example, if I have an "auth" Route Service that injects a header to identify the authenticated user to an application using that auth service. You cannot allow direct access to that application because that would enable a header injection attack on that application. Another example, if the Route Service were a rate limit service then direct access to application instances would allow apps to circumvent rate limits. Applications using a Route Service require that the app only be accessed through a router and not any other way. If I have a security group that enables direct access to DEAs then apps with that security group enabled will be able will be able to circumvent the Route Service.
Their may be ways to get around this restriction using shared secrets between Route Services and the app but they'd require apps to code to the Route Service explicitly which I think would be sub optimal.
I want my deployment to support both apps that can do their own route discovery and apps that can use Route Services.
Dieu proposed that I could use something like placement pools (when they come) to fragment my deployment. And require apps that want to do their own service discovery be deployed to their own placement pool. I'm not a fan of this type of deployment fragmentation.
I think their are other options that could allow both service discovery apps and Route Services apps to exist side by side without the need to fragment my deployment. Here are some options I see:
* Add support for ingress rules to security groups. Spaces that wish to deploy Service Discovery apps would enable broader inbound access. By default spaces could be restricted to only accept requests from routers.
* If the DEA notices that an application is using Route Services, only allow, that application to receive connections from routers.
* Have the router sign a header to prove the request is coming from it. Then have the DEA filter requests into the container to validate the signed header to ensure the request came from a router before passing the request onto the app.
Those are a few thoughts. Does that help clarify my concern Zach?
Thanks,
Mike