Re: Routing for Isolation Segments


Mike Youngstrom <youngm@...>
 

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.



Join cf-dev@lists.cloudfoundry.org to automatically receive all group messages.