Routing for Isolation Segments

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 apps within the segment. This topic includes the following sections:

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

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 apps from another. However, these apps still share the same network resources. Requests for apps on all isolation segments, as well as for system components, transit the same load balancers and Cloud Foundry routers.

When you use isolation segments, Pivotal Application Service (PAS) designates its Diego Cells as belonging to an isolation segment called shared. This 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 Installing PCF Isolation Segment.

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:

Is distinct domains

Use cases include:

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

  • 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 back ends, 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. For example, an operator who wants one isolation segment separated from their PAS Diego Cells could create one network named sample-network with two subnets named sample-subnet- and sample-subnet-is1.

The following diagram describes the network topology:

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

Subnets do not generally span IaaS availability zones (AZs), so the same operator with two AZs needs four subnets.

IaaS network: sample-network
|
|_____ IaaS subnet: sample-subnet--az1
|
|_____ IaaS subnet: sample-subnet--az2
|
|_____ IaaS subnet: sample-subnet-is1-az1
|
|_____ IaaS subnet: sample-subnet-is1-az2

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

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. For more information, see Usage in the BOSH documentation.

Go to the Assign AZs and Networks pane of the PCF Isolation Segment tile to assign your isolation segment to the network you created in Step 1. For more information, see Installing PCF Isolation Segment.

Step 3: Configure Additional Routers

Go to the Resource Config pane of the PCF Isolation Segment tile and use the dropdown to set your Router instances to a number greater than zero. For more information, see Installing PCF Isolation Segment.

Step 4: Add Routers to Load Balancer

If your IaaS supports it, go to the Resource Config pane of the PCF Isolation Segment tile and enter the name of your load balancer under Load Balancers. For more information, see Installing PCF Isolation Segment. 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 app may be deployed to only one isolation segment, requests should only reach a router that has access to the apps 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 apps for that domain are deployed.

Shared Domain Name

It is a common requirement for apps 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 PAS Diego Cells.

  • 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 for necessary ingress and egress traffic for isolation segments and PAS Diego Cells. 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 app in a different isolation segment.

To configure firewall rules for isolation segment traffic:

  1. 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
    -to-bosh PAS isolation segment tcp BOSH Director BOSH Agent on VMs in the PAS Diego Cells to reach BOSH Director
    bosh-to- BOSH Director tcp PAS Diego Cells BOSH director to control VMs in the PAS Diego Cells
    -internal PAS Diego Cells tcp PAS Diego Cells VMs within the PAS Diego Cells to reach one another
    -to-is1 PAS Diego Cells tcp:1801,8853,9100 Isolation segment Diego BBS in PAS Diego Cells to reach Diego Cells in isolation segment
    is1-to-bosh Isolation segment tcp:4222,25250,25777 BOSH Director BOSH agent on VMs in isolation segment to reach BOSH Director
    is1-internal Isolation segment tcp Isolation segment VMs within isolation segment to reach one another
    is1-to- Isolation segment tcp:3000,3457,4003
    4103,4222,8080
    8082,8083,8443,8447,8844
    8853,8889,8891
    9000,9022,9023,9090,9091


    For information about the processes that use these ports and their corresponding manifest properties, see Port Reference Table.
    PAS Diego Cells Diego Cells in isolation segment to reach BBS, Auctioneer, and CredHub in PAS Diego Cells. Loggregator Agent to reach Traffic Controller. Routers to reach NATS, UAA, and Routing API.
  2. (Optional) Configure the firewall rules in the table below:

    Rule Name Source Allowed Protocols/Ports Destination Reason
    jumpbox-to-is1 Jumpbox VM tcp:22 Isolation segment Jumpbox VMs to reach isolation segment through SSH or BOSH SSH.
    is1-to-jumpbox Isolation segment tcp Jumpbox VM Isolation segment to reach jumpbox VM. Opens reverse SSH or BOSH SSH tunnel from jumpbox VM to isolation segment.
    diego-cell-egress Diego Cell VM on isolation segment tcp Internet If Diego Cells must download buildpacks to stage apps, allow egress traffic from all Diego Cell VMs on isolation segments to reach the Internet.

For more information about ports used by agents to communicate with BOSH, see the bosh-deployment repository on GitHub.

For more information about networks and firewall rules for GCP, see Using Subnetworks in the GCP documentation.

Port Reference Table

See the following table to understand which protocols and ports map to which processes and manifest properties for the is1-to- rule above.

Protocol Port Process Manifest Property
tcp 3000 Routing API routing_api.port
tcp 3457 Doppler metron_endpoint.dropsonde_port
tcp 4003 VXLAN Policy Agent cf_networking.policy_server.internal_listen_port
tcp 4103 Silk Controller cf_networking.silk_controller.listen_port
tcp 4222 NATS router.nats.port
tcp 8080 Diego file server - HTTP diego.file_server.listen_addr
tcp 8082 Doppler gRPC loggregator.doppler.grpc_port
tcp 8083 Reverse Log Proxy Gateway (cf auth proxy) loggregator.reverse_log_proxy_gateway_cf_auth_proxy.proxy_port
tcp 8443 UAA uaa.ssl.port
tcp 8447 Diego file server - HTTPS file_server.https_listen_addr
tcp 8844 CredHub credhub.port
tcp 8853 BOSH DNS health health.server.port from bosh-dns-release
tcp 8889 Diego BBS diego.rep.bbs.api_location
tcp 8891 Diego Database (Locket) diego.locket.listen_addr
tcp 9000 Loggregator Syslog Binding Cache loggr-syslog-binding-cache.external_port
tcp 9022 CC stager capi.stager.cc.external_port
tcp 9023 CC TPS capi.tps.cc.external_port
tcp 9090 CC uploader http_port
tcp 9091 CC uploader https_port

Additional GCP Information

For more information, see Understanding backend services in the GCP documentation and the bosh-google-cpi-release repository on GitHub.

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 apps in the same isolation segment.
  1. In the Networking pane of the Pivotal Application Service (PAS) tile, enable the Routers reject requests for Isolation Segments checkbox.
  2. 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.
  1. In the Networking pane of the PAS tile, enable the Routers reject requests for Isolation Segments checkbox.
  2. 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 disabled. 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:

origin:"gorouter" eventType:ValueMetric timestamp:1491338040750977602 deployment:"superman.cf-app.com" job:"router_is1" index:"9a4b639c-8f0e-4b2b-b332-4161ee4646e6" ip:"10.0.16.23" valueMetric:<name:"uptime" value:118 unit:"seconds" >