Routing for Isolation Segments

This topic describes how operators can configure and manage routing for isolation segments in VMware Tanzu Application Service for VMs (TAS for VMs). Operators can deploy an additional set of Gorouters for each isolation segment to handle requests for apps within the segment.

For more information about how isolation segments work, see Isolation Segments in TAS for VMs Security. For more information about creating isolation segments, see Installing 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, TAS for VMs Gorouters, and TAS for VMs TCP Routers.

When you use isolation segments, TAS for VMs 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 Isolation Segment.

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

The two isolation segments each contain a single Diego Cell. These isolation segments use the same Gorouter, TCP Router, and load balancers.

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

The two isolation segments each use separate Gorouters and Diego Cells. However, the use of an isolated TCP router in this scenario is not supported.

Use cases include:

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

• The TAS for VMs 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 TAS for VMs Gorouters, each load balancer requires an additional deployment of Gorouters.

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 TAS for VMs Diego Cells could create one network named sample-network with two subnets named sample-subnet-tas and sample-subnet-is1.

The diagram below describes the network topology:

IaaS network: sample-network
  |
  |_____ IaaS subnet: sample-subnet-tas
  |
  |_____ 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-tas-az1
|
|_____ IaaS subnet: sample-subnet-tas-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 Gorouters

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 Isolation Segment tile to assign your isolation segment to the network you created in Step 1. For more information, see Step 3: Configure the Tile in Installing Isolation Segment.

Step 3: Configure Additional Gorouters

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

Step 4: Add Gorouters to Load Balancer

If your IaaS supports it, go to the Resource Config pane of the Isolation Segment tile and enter the name of your load balancer under Load Balancers. For more information, see Step 3: Configure the Tile in Installing 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 Gorouter instance group, and configure DNS to resolve these domain names to a load balancer that routes requests to the matching Gorouters.

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

As Gorouter 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 Gorouter that has access to the apps for that domain name. Load balancing requests for a domain across more than Gorouter instance group can result in request failures unless all the Gorouter 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 Gorouter instance group, create a new TAS for VMs 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 Gorouters for the TAS for VMs Diego Cells.

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

The three isolation segments each use separate Gorouters and load balancers.

Step 6: Configure Firewall Rules

Configure firewall rules to allow for necessary ingress and egress traffic for isolation segments and TAS for VMs 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 Gorouter 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.

   For information about the processes that use these ports and their corresponding manifest properties, see Port Reference Table.

   Rule Name	Source	Allowed Protocols/Ports	Destination	Reason
   tas-to-bosh	TAS for VMs Diego Cells	tcp:4222, 25250, 25777	BOSH Director	BOSH Agent on VMs in the TAS for VMs Diego Cells to reach BOSH Director
   tas-internal	TAS for VMs Diego Cells	tcp:any, udp:any, icmp:any	TAS for VMs Diego Cells	VMs within the TAS for VMs Diego Cells to reach one another
   tas-to-is1	TAS for VMs Diego Cells	tcp:1801, 8853, 9100	Isolation segment	Diego BBS in TAS for VMs 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:all, udp:all, icmp:all	Isolation segment	VMs within isolation segment to reach one another
   is1-to-tas	Isolation segment	tcp:3000, 3001, 4003, 4103, 4222, 4224, 4443, 6067, 8080, 8082, 8083, 8443, 8447, 8844, 8853, 8889, 8891, 9000, 9022, 9023, 9090, 9091	TAS for VMs Diego Cells	Diego Cells in isolation segment to reach Diego BBS, Diego Auctioneer, and CredHub in TAS for VMs. Loggregator Agent to reach Doppler. Syslog Agent to reach Log Cache Syslog Server. Gorouters to reach NATS, UAA, and Routing API. Metrics Discovery Registrar to reach NATS.

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.
   diego-cell-egress	Diego Cell VM on isolation segment	tcp:any, udp:any	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

To understand which protocols and ports map to which processes and manifest properties for the rules above, see the table below:

Protocol	Port	Process	Manifest Property
tcp	1801	Diego Rep	diego.rep.listen_addr_securable
tcp	3000	Routing API	routing_api.port
tcp	3001	Routing API	routing_api.mtls_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	nats.nats.port
tcp	4224	NATS	nats-tls.nats.port
tcp	4443	CAPI Blobstore Port - HTTPS	capi.blobstore.tls.port
tcp	6067	Log Cache Syslog Server	log-cache.log-cache-syslog-server.syslog_port
tcp	8080	CAPI Blobstore Port - HTTP, Diego file server - HTTP	capi.blobstore.port, diego.file_server.listen_addr
tcp	8082	Doppler gRPC, Reverse Log Proxy Gateway	loggregator.doppler.grpc_port, loggregator.reverse_log_proxy.egress.port
tcp	8083	Log Cache cf-auth-proxy	log-cache.log-cache-cf-auth-proxy.proxy_port
tcp	8084	Diego file server - HTTP	diego.file_server.listen_addr
tcp	8443	UAA	uaa.uaa.ssl.port
tcp	8447	Diego file server - HTTPS	diego.file_server.https_listen_addr
tcp	8844	CredHub	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	Cloud Controller Stager	capi.stager.cc.external_port
tcp	9023	Cloud Controller TPS	capi.tps.cc.external_port
tcp	9090	Cloud Controller Uploader	capi.cc_uploader.http_port
tcp	9091	Cloud Controller Uploader	capi.cc_uploader.https_port
tcp	9100	System Metrics Scraper	system-metrics-scraper.loggr-system-metric-scraper.scrape_port
tcp	25250	BOSH Blobstore	bosh.blobstore.port
tcp	25777	BOSH Registry	bosh.registry.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 Gorouters for Isolation Segments

You can configure Gorouter 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 Gorouter dedicated to an isolation segment that only recognizes routes for apps in the same isolation segment.	In the Networking pane of the TAS for VMs tile, select "Reject all" for the Gorouter isolation segment request handling radio button. Set the Gorouter sharding mode in the Isolation Segment tile to Isolation segment only.
Deploying additional Gorouters for TAS for VMs	The flexibility of the configuration also supports deployment of a Gorouter that excludes all isolation segments.	In the Networking pane of the TAS for VMs tile, select "Reject all" for the Gorouter isolation segment request handling radio button. Set the Gorouter sharding mode in the Isolation Segment tile to No isolation segment.

Note: For compute isolation only, you can select "Accept all" for the Gorouter isolation segment request handling radio button. This is the default setting, which does not require any additional Gorouters for the Isolation Segment tile.

Metrics for Gorouters Associated with Isolation Segments

For metrics emitted by the Gorouter, metrics can be distinguished by the name of the job. For example, this 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" >