Hi Mike,

Thank you for the feedback.

Without access control for domains, a developer could map route
foo.example.com (for which the LB will route requests only to the router
group for IS-1) to an app in a space associated with IS-2.

If the routing table is not partitioned, both router groups will have the
route in their routing tables. If the LB is correctly configured, it will
route requests for foo.example.com only to the router group for IS-1. The
routers will attempt to route the request. Assuming the firewalls are
configured correctly, the routers will return a 502.

If the routing table is partitioned, only the router group for IS-2 will
have the route in its routing table. If the LB is correctly configured, it
will route requests for foo.example.com only to the router group for
IS-1. The routers will reject the request immediately, returning a 404.

Either way, the developer is set up for failure.

Shannon Coen
Product Manager, Cloud Foundry
Pivotal, Inc.

On Tue, Jan 24, 2017 at 9:05 AM, Mike Youngstrom <youngm(a)gmail.com> wrote:

Question, Just want to make sure I'm following you. In your Access
Control example you mention that without access control a developer would
be able to create a route to foo.example.com in a space associated with
IS-2, but, that "route will fail". Is this example assuming that the
"Partitioning the Routing Table" feature was implemented, a properly
configured firewalls, or would the route fail for some other reason?

I think for our use cases we only require Access Control. We are capable
of configuring our firewalls and such correctly. :) Partitioned routing
tables would be nice too but I think a lower priority.

Mike

On Mon, Jan 23, 2017 at 6:24 PM, Shannon Coen <scoen(a)pivotal.io> wrote:

Last week the CF Routing team incepted on enhancements for dedicated
deployments of the CF routers for isolation segments.

- Original proposal
<https://docs.google.com/document/d/1FFW8YwKeBK1DuSXFHH_wxGpSZpOpkPN5yOUB-03whsI/edit?usp=sharing>
- Summary
<https://docs.google.com/presentation/d/1D4aguVXHtTGdhFPAqAC1exZd0Nrh2o4VO3PR4kmHvq4/edit?usp=sharing>


For those of you who are looking forward to leveraging isolation
segments for your use cases, we'd like to know whether you would be
inclined to use dedicated routing tiers for isolation groups in production
without the proposed enhancements below, or whether you would require
either/both of the enhancements we have in mind.

*Current Support*

With compute-only isolation, an application can be deployed to an
isolated pool of Diego Cells. On its own, this design will rely on a shared
routing tier with access to all isolation segments. This requires an
operator to carefully configure their load balancer and firewall rules to
prevent an attacker using a spoofed Host header to reach an application
that shouldn't be publicly routable.

An operator can currently deploy dedicated deployments of routers for an
isolation segment but the routing table will be shared among them. Should a
misconfigured load balancer forward a request to routers for an app on
another isolation segment, the routers will attempt to route the request.
If the firewall is correctly configured, the router will return a 502. If
the firewall is misconfigured, a private app may be publicly accessible.

*Proposed Enhancement: Partitioning the Routing Table*

By partitioning the routing table, routers dedicated to a isolation
segment will only route requests for apps in an associated isolation
segment; if a load balancer were misconfigured, and a request for an app in
another isolation segment were forwarded to the routers, a 404 would be
returned.

*Proposed Enhancement: **Access Control*

An org may have multiple domains and multiple isolation segments. A
space is associated with only one isolation segment.

Example: if the operator has configured their LB to point *.
foo.example.com at routers for isolation segment IS-1 and *.
bar.example.com at routers for isolation segment IS-2, there's nothing
preventing an app developer from creating a route from domain
foo.example.com in a space associated with IS-2. Requests to the route
will fail and the developer would not know why. To prevent this, we'll
enable API clients to filter domains by targeted space, so that a developer
only sees domains from which they can create working routes.

*Your Feedback*

Please let us know if you would require either of these enhancements for
routing to isolation segments in your production environments.

Thank you,

Shannon Coen
Product Manager, Cloud Foundry
Pivotal, Inc.