Re: Routing for Isolation Segments


Guillaume Berche
 

Hi Shannon,

Thanks for the feedback solicitation on this feature, and for sharing the
inception summary material with the community.

In the case of Orange, the partitioned routing table is a must for running
IS in production. The Access control would be useful as to enhance the user
experience in the CLI, and reduce troubleshooting burden to CF operators,
but wouldn't account to the security ratings evaluated for onboarding
sensitive apps in CF. We see it important as well but of lower priority
than partitioned routing table.

One use case we have for IS is to have an IS for production internet facing
application, and one IS for intranet facing application.The partitioned
routing table protects intranet facing applications being exposed on the
internet in case of a faulty load balancer configuration.

I added also some misc comments to the inception summary slides.

Besides, I did not see mention in the summary material of the access
control to NATS or routing API per isolation segment, as to account for the
discussed compromise scenario [1] below. This is likely to be a must for
our organization to be able to leverage isolation segments: CVE-2016-6655
[2] makes some people in our organization judge that such vulnerabilities
make the compromise scenario below realistic and too risky for some of our
applications that would have liked to benefit a CF instance leveraging IS.

Compromise scenario: the compromise of an IS1 could allow an attacker to
compromise another IS2 through the shared control plane (NATS or routing
API in this case). Potentially exploitable compromise across IS could be
(in the case of the shared routing control plane) to alter another IS
routing table resulting in:
- denial of service (unregistering all routes into another IS),
- routing traffic to a malicious route service, being therefore able to
sniff all traffic from another IS.

I wonder whether there is still a 2nd phase plan to address this compromise
scenario and if so, if you could share some details.

Thanks again,

Guillaume.

[1]
https://docs.google.com/document/d/1FFW8YwKeBK1DuSXFHH_wxGpSZpOpkPN5yOUB-03whsI/edit?disco=AAAAA4X5De0
[2]
http://cf-dev.70369.x6.nabble.com/cf-dev-CVE-2016-6655-Utility-script-command-injection-tt5922.html#a5961

On Wed, Jan 25, 2017 at 3:12 AM, Mike Youngstrom <youngm(a)gmail.com> wrote:

Got it, so what I said before hold. We view access control as a must and
partitioned routing table a nice to have.

Thanks,
Mike

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

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.



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