Routing for Isolation Segments

Page last updated:

This topic describes how operators can configure and manage routing for isolation segments. Operators can deploy an additional set of routers for each isolation segment to handle requests for applications within the segment. This topic includes the following sections:

Note: The instructions in this topic assume you are using Google Cloud Platform (GCP). The procedures may differ on other IaaSes, but the concepts should be transferable.

Overview

Isolation segments isolate the compute resources for one group of applications from another. However, these applications still share the same network resources. Requests for applications on all isolation segments, as well as for system components, transit the same load balancers and Cloud Foundry routers.

A shared Isolation Segment is the default isolation segment assigned to every org and space. This can be overwritten by assigning an explicit default for an organization. For more information about creating isolation segments, see the Installing PCF Isolation Segment topic.

Operators who want to prevent all isolation segments and system components from using the same network resources can deploy an additional set of routers for each isolation segment:

Use cases include:

Requests for applications in an isolation segment must not share networking resources with requests for other applications.

The Cloud Foundry management plane should only be accessible from a private network. As multiple IaaS load balancers cannot typically share the same pool of backends, such as Cloud Foundry routers, each load balancer requires an additional deployment of routers.

Step 1: Create Networks

Create a network or subnet for each isolation segment on your infrastructure

As an example, an operator who wants one shared isolation segment and one private segment could create one network named sample-network with two subnets named sample-subnet-shared, sample-subnet-is1.

Step 2: Configure Networks for Routers

To configure the subnets with Bosh, use Bosh Cloud Config subnets. Each subnet in the IaaS should correspond to a Bosh subnet that is labeled with the correct isolation segment

Navigate to the Assign AZs and Networks section of the PCF Isolation Segment tile to assign your isolation segment to the network you created in Step 1. See the Installing PCF Isolation Segment topic for more information.

Step 3: Configure Additional Routers

Navigate to the Resource Config section of the PCF Isolation Segment tile and use the dropdown menu to set your Router instances to a number greater than zero. See the Installing PCF Isolation Segment topic for more information.

Step 4: Add Routers to Load Balancer

If your IaaS supports it, navigate to the Resource Config section of the PCF Isolation Segment tile and enter the name of your load balancer under Load Balancers. See the documentation specific to your IaaS in Installing Pivotal Cloud Foundry for more information. If your IaaS does not support this configuration, you must create static IP addresses and assign them to your load balancer out of band.

Step 5: Configure DNS and Load Balancers

Create a separate domain name for each router instance group, and configure DNS to resolve these domain names to a load balancer that routes requests to the matching routers.

Note: You must configure your load balancers to forward requests for a given domain to one router instance group only.

As router instance groups may be responsible for separate isolation segments, and an application may be deployed to only one isolation segment, requests should only reach a router that has access to the applications for that domain name. Load balancing requests for a domain across more than router instance group can result in request failures unless all the router instance groups have access to the isolation segments where applications for that domain are deployed.

Shared Domain Name

It is a common requirement for applications on separate isolation segments to be accessible at domain names that share a domain, such as private-domain.com. To achieve this configuration while also obeying the guideline for forwarding requests for a domain to only one router instance group, create a new Cloud Foundry domain for a needed subdomain, such as *.foo.private-domain.com.

The diagrams illustrate a topology with separate load balancers, but you could also use one load balancer with multiple interfaces. In this configuration:

Requests for system domain *.cf-system.com and the shared domain *.shared-apps.com are forwarded to the routers for the shared isolation segment.

Requests for private domain *.foo.private-domain.com are forwarded to the routers for IS1.
Requests for private domain *.private-domain.com are forwarded to the routers for IS2.

Step 6: Configure Firewall Rules

Configure firewall rules to allow for necessary ingress and egress traffic for private and shared isolation segments. Assuming a default deny-all rule, properly configuring firewall rules prevents a request with a spoofed Host header from being forwarded by a router to an application in a different isolation segment.

To configure firewall rules for isolation segment traffic, do the following:

Configure the firewall rules in the table below:

Note: Firewall rules are specific to each IaaS, so the exact definition of Source and Destination depends on the IaaS. For example, on GCP, a Source is a subnet and a Destination is a tag. On AWS, both Source and Destination are security groups.

Rule Name

Source

Allowed Protocols/Ports

Destination

Reason

shared-to-bosh

Shared isolation segment

tcp

BOSH Director

BOSH Agent on VMs in the shared isolation segment to reach BOSH Director

Additional GCP Information

Sharding Routers for Isolation Segments

You can configure router sharding for isolation segments depending on your use case:

Use Case

Description

How to Configure

Securing apps that run in an isolation segment

To provide security guarantees in addition to the firewall rules described above, you can configure sharding of the Gorouter’s routing table, resulting in a router dedicated for an isolation segment having knowledge only of routes for applications in the same isolation segment.

In the Networking configuration pane of the Pivotal Application Service (PAS) tile, select the checkbox labeled Routers reject requests for Isolation Segments.

Set the Router Sharding Mode in the isolation segment tile to Isolation Segment Only.

Deploying additional routers for PAS

The flexibility of the configuration also supports deployment of a router that excludes all isolation segments.

In the Networking configuration pane of the PAS tile, select the checkbox labeled Routers reject requests for Isolation Segments.

Set the Router Sharding Mode in the isolation segment tile to No isolation Segment.

Note: For compute isolation only, you can leave the Routers reject requests for isolation segments checkbox unselected in the PAS Networking pane. This is the default setting, which does not require any additional routers for the Isolation Segment tile.

Metrics for Routers Associated with Isolation Segments

For metrics emitted by the Gorouter, metrics can be distinguished by the name of the job.
For example, the following line is a metric emitted on uptime: