LATEST VERSION: 1.10 - CHANGELOG
Pivotal Cloud Foundry v1.10

Routing 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.

For more information about how isolation segments work, see the Isolation Segments section of the Understanding Cloud Foundry Security topic. For more information about creating isolation segments, see the Installing PCF Isolation Segment topic.

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.

The illustration below shows isolation segments sharing the same network resources.

Routing is

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 two private segments could create one network called sample-network with three subnets called sample-subnet-shared, sample-subnet-is1, and sample-subnet-is2.

The following diagram describes the network topology:

IaaS network: sample-network
  |
  |_____ IaaS subnet: sample-subnet-shared
  |
  |_____ IaaS subnet: sample-subnet-is1
  |
  |_____ IaaS subnet: sample-subnet-is2

For more information about networks and subnets in GCP, see the Using Networks and Firewalls topic in the GCP documentation.

Step 2: Configure Networks for Routers

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.

The sections below describe a configuration that routes applications from distinct domain names, and a configuration that routes applications from a shared domain name. The diagrams illustrate a topology with separate load balancers, but you could also use one load balancer with multiple interfaces.

Distinct Domain Names

In a configuration that routes applications from distinct domain names:

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

Is distinct domains

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-apps.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-apps.com.

In this configuration:

  • Requests for system domain *.cf-system.com and the shared domain *.cf-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.

Is sharing domains

Step 6: Configure Firewall Rules

Configure firewall rules to allow necessary traffic between the shared isolation segments (sample-shared-is) and the private isolation segments (sample-is1 and sample-is2). Assuming a default deny-all rule, these rules should prevent a request with a spoofed Host header from being forwarded by a router to an application in another isolation segment.

Rule Name Source subnetwork Allowed Protocols/Ports Target Tags Reason
shared-to-bosh sample-subnet-shared tcp:22,6868,25555,
4222,25250
sample-bosh BOSH Agent on VMs in sample-shared-is to reach BOSH Director
shared-internal sample-subnet-shared tcp sample-shared-is VMs within sample-shared-is to reach one another
shared-to-is1 sample-subnet-shared tcp:1801 sample-is1 Diego BBS in sample-shared-is to reach Cells in sample-is1
shared-to-is2 sample-subnet-shared tcp:1801 sample-is2 Diego BBS in sample-shared-is to reach Cells in sample-is2
is1-to-bosh sample-subnet-is1 tcp:22,6868,25555,
4222,25250
sample-bosh BOSH agent on VMs in sample-is1 to reach BOSH Director
is1-internal sample-subnet-is1 tcp sample-is1 VMs within sample-is1 to reach one another
is1-to-shared sample-subnet-is1 tcp:8300-8500,8889,4443,9016,
8080,9090,3457,9022
sample-shared-is Diego Cells in sample-is1 to reach BBS and Auctioneer in sample-shared-is, Consul Agent to reach Consul, Metron Agent to reach Traffic Controller, and Routers to reach NATS, UAA, and Routing API
is2-to-bosh sample-subnet-is2 tcp:22,6868,25555,
4222,25250
sample-bosh BOSH agent on VMs in sample-is2 to reach BOSH Director
is2-internal sample-subnet-is2 tcp sample-is2 VMs within sample-is2 to reach one another
is2-to-shared sample-subnet-is2 tcp:8300-8500,8889,4443,
9016,8080,9090,3457,9022
sample-shared-is Diego Cells in sample-is2 to reach BBS and Auctioneer in sample-shared-is, Consul Agent to reach Consul, Metron Agent to reach Traffic Controller, and Routers to reach NATS, UAA, and Routing API

For more information consult the following topics:

  • The bosh-deployment GitHub repo contains documentation describing ports used by agents to communicate with BOSH.
  • The “Using Subnetworks” topic in the GCP documentation describes networks and firewall rules in the “Isolation of Subnetworks” section.

Additional GCP Information

For more information, see the following:

  • “Backend Services” in the GCP documentation
  • BOSH Google Compute Engine CPI GitHub repo
Create a pull request or raise an issue on the source for this page in GitHub