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:

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 Managing Isolation Segments 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 named sample-network with three subnets named 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

Below is a sample excerpt of a BOSH v2 Cloud Config file for GCP that includes the three example subnets described above. Each subnet is associated with one BOSH AZ. For the purpose of compute isolation, each BOSH AZ is associated with a different IaaS AZ.


azs:
- name: z1
  cloud_properties:
    zone: us-east1-b
- name: z2
  cloud_properties:
    zone: us-east1-c
- name: z3
  cloud_properties:
    zone: us-east1-d
networks:
- name: private
  type: manual
  subnets:
  - range: 10.0.0.0/16
    gateway: 10.0.0.1
    reserved:
    - 10.0.16.2-10.0.16.3
    - 10.0.31.255
    static:
    - 10.0.31.190-10.0.31.254
    az: z1
    cloud_properties:
      ephemeral_external_ip: true
      network_name: sample-network
      subnetwork_name: sample-subnet-shared
      tags:
      - sample-shared-is
  - range: 10.1.16.0/20
    gateway: 10.1.16.1
    reserved:
    - 10.1.16.2-10.1.16.3
    - 10.1.31.255
    static:
    - 10.1.31.190-10.1.31.254
    az: z2
    cloud_properties:
      ephemeral_external_ip: true
      network_name: sample-network
      subnetwork_name: sample-subnet-is1
      tags:
      - sample-is1
  - range: 10.1.32.0/20
    gateway: 10.1.32.1
    reserved:
    - 10.1.32.2-10.1.32.3
    - 10.1.47.255
    static:
    - 10.1.47.190-10.1.47.254
    az: z3
    cloud_properties:
      ephemeral_external_ip: true
      network_name: sample-network
      subnetwork_name: sample-subnet-is2
      tags:
      - sample-is2

Step 3: Configure Additional Routers

You must edit the BOSH deployment manifest to include an instance group for each set of routers.

The sample BOSH v2 manifest snippet below includes additional instance groups for the routers of each isolation segment, each associated with different BOSH AZs. As a result, a router instances will be configured with IP addresses from different subnets.

Note: For a high-availability deployment assign each subnet to at least two AZs, use at least two instances of each instance group, and assign each instance group to at least two BOSH AZs.

Note: When deploying with a BOSH v2 style manifest, that leverages `instance_groups`, you must enable UAA to differentiate between links exported by the Gorouters, as it will only accept connections from one instance group of Gorouters. As you may have multiple isolation segments, we recommend renaming the instance group used for the system domain. You will also need to specify the name of the link that UAA consumes the link from.


instance_groups:
- name: router
  instances: 1
  azs:
  - z1
  networks:
  - name: private
  jobs:
  - name: gorouter
    provides:
      gorouter: {as: router_primary}
- name: uaa
  jobs:
  - name: uaa
    consumes:
      router: {from: router_primary}
- name: router-is1
  instances: 1
  azs:
  - z2
  networks:
  - name: private
- name: router-is2
  instances: 1
  azs:
  - z3
  networks:
  - name: private
- name: cell-is1
  instances: 1
  azs:
  - z2
  networks:
  - name: private
- name: cell-is2
  instances: 1
  azs:
  - z3
  networks:
  - name: private

Step 4: Add Routers to Load Balancer

For some IaaS (e.g. AWS, GCP), the BOSH Cloud Config and deployment manifest can be used to instruct BOSH to add routers to the IaaS load balancers automatically. For others, operators must assign static IPs to the routers in the manifest and assign these IPs to the load balancers out of band.

For deployments to GCP, associate the router instance groups with load balancers by first configuring a backend service which describes the load balancer rules. Next, define the backend service in the Cloud Config with a vm_extension. Finally, associate the router instance groups with the vm_extention. In the following example, the vm_extension named cf-router-network-properties is defined in the Cloud Config with a GCP backend service.

Note: If necessary, configure a firewall rule to allow traffic from your load balancer to the Gorouters.

  instance_groups:
  - name: router-is1
    instances: 1
    azs:
    - z2
    networks:
    - name: private
    vm_extensions:
    - cf-router-network-properties

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:9090,9091,8082,8300,
8301,8302,8889,8443,3000,
4443,8080,3457,9023,9022,
4222
udp:8301,8302,8600

See Port Reference Table for information about the processes that use these ports and their corresponding manifest properties.
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:9090,9091,8082,8300,
8301,8302,8889,8443,3000,
4443,8080,3457,9023,9022,
4222
udp:8301,8302,8600

See Port Reference Table for information about the processes that use these ports and their corresponding manifest properties.
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.

Port Reference Table

See the following table to understand which protocols and ports map to which processes and manifest properties for the is#-to-shared rules above.

Protocol Port Process Manifest Property
tcp 9091 CC uploader https_port
tcp 9090 CC uploader http_port
tcp 9023 CC TPS capi.tps.cc.external_port
tcp 9022 CC stager capi.stager.cc.external_port
tcp 8889 Diego BBS diego.rep.bbs.api_location
tcp 8082 Doppler gRPC loggregator.doppler.grpc_port
tcp 8080 Diego file server diego.file_server.listen_addr
tcp 8443 UAA uaa.ssl.port
tcp 8302 Consul**
tcp 8301 Consul**
tcp 8300 Consul**
tcp 4222 NATS router.nats.port
tcp 3457 Doppler metron_endpoint.dropsonde_port
tcp 3000 Routing API routing_api.port
udp 8301 Consul**

** Consul documentation: Ports Used

Additional GCP Information

For more information, see the following:

  • “Backend Services” in the GCP documentation
  • BOSH Google Compute Engine CPI GitHub repo

Sharding Routers for Isolation Segments

To provide security guarantees in addition to the firewall rules described above, an operator can configure sharding of 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. The flexibility of the configuration also supports deployment of a router that is responsible for multiple isolation segments, or that excludes all isolation segments.

Bypass Cloud Controller Bridge

Support for router sharding depends on bypassing the Cloud Controller Bridge (CC Bridge). To do so, set the cc.diego.temporary_local_apps flag to true in your Cloud Config file. This enables the Cloud Controller to send app creation requests containing routing isolation segment information directly to the Diego BBS, rather than through the CC Bridge.

Below is a BOSH Ops File that can be used to update the cf-deployment manifest:


# enable bridge consumption to allow iso seg routing info to get to diego
# cloud_controller_ng
- type: replace
  temporary_local_apps: &temporary_local_apps true
  path: /instance_groups/name=api/jobs/name=cloud_controller_ng/properties/cc?/diego?/temporary_local_apps?
  value: *temporary_local_apps

# cc-worker
- type: replace
  path: /instance_groups/name=cc-worker/jobs/name=cloud_controller_worker/properties/cc?/diego?/temporary_local_apps?
  value: *temporary_local_apps

# cc-clock
- type: replace
  path: /instance_groups/name=cc-clock/jobs/name=cloud_controller_clock/properties/cc?/diego?/temporary_local_apps?
  value: *temporary_local_apps

Configure Routers for Sharding

Configuration is achieved using two manifest properties, routing_table_sharding_mode and isolation_segments.

The three supported values of routing_table_sharding_mode are all, shared-and-segments, and segments.

  • all: All routes will be registered. This is the default mode to preserve Gorouter’s existing behavior.
  • shared-and-segments: Both routes configured with manifest property isolation_segments and routes without an isolation segment specified will be registered.
  • segments: Only routes for the configured isolation segments will be registered.

You can provide a list of isolation segments using the manifest property isolation_segments.

The following table describes the behaviors that you can achieve with these two properties:

Sharding Mode Isolation Segments Routes Registered
all none All routes
all provided All routes
shared-and-segments none Routes that are not associated with an isolation segment
shared-and-segments provided Routes that are not associated with an isolation segment, as well as routes for the specified isolation segments. Routes for other isolation segment will be excluded.
segments none Invalid combination. Deploy will fail.
segments provided Routes for specified isolation segments only.

For example, the following configuration in a deployment manifest describes a deployment with one router in the shared segment and another router in a separate isolation segment is1:

jobs:
- name: router_shared
  properties:
    router:
      isolation_segments: []
      routing_table_sharding_mode: shared-and-segments
...
- name: router_is1
  properties:
    router:
      isolation_segments:
      - is1
      routing_table_sharding_mode: segments

The router_shared router will register all routes that do not have an isolation_segment value. The router_is1 router will only register routes that have an isolation_segment value of is1.

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" >
Create a pull request or raise an issue on the source for this page in GitHub