Restricting app access to internal TAS for VMs components

You can secure the virtual machines (VMs) component of your VMware Tanzu Application Service for VMs (TAS for VMs) deployment from being accessed by apps. Here are the instructions.

App access basics

See the following list to interpret the concepts for this topic:

How TAS for VMs determines where apps can send traffic:
- TAS for VMs uses App Security Groups (ASGs), which are network policy rules specifying protocols, ports, and IP ranges that apply to outbound network connections initiated from apps. For more information, see App Security Groups.
Why you must create new rules for outbound app traffic:
- TAS for VMs installs with a default ASG that you can run for apps on your deployment that send traffic to almost any IP address. This results in apps not being blocked from initiating connections to most network destinations unless an administrator takes action to update the ASGs with a more restrictive policy. For more information, see the Default ASGs section of the App Security Groups topic.

How you can set up new rules:

To help secure your component VMs against apps while ensuring your apps can access the services they need, follow the steps in the Procedure section, which includes:

Step	Description
1	Determine your network layout: The procedure for securing your deployment with ASGs varies depending on your network layout, which you can determine using Tanzu Operations Manager.
2	Ensure access for TAS for VMs system apps Bind the default ASG to the `system` org so that TAS for VMs system apps can continue accessing the system components they need after you remove the deployment-wide default ASG in Step 4.
3	Create new ASGs: Block apps from sending traffic to system components, but allow them to send traffic to the services they need.
4	Remove the default ASG: After you create and bind new ASGs, you no longer need the deployment-wide default ASG bindings that allow apps to send traffic to any IP.
5	Restart your apps: To apply the ASG changes, you must restart all of the apps in your deployment.

When to set up new rules:
- VMware recommends that you complete this procedure directly after installing TAS for VMs and before developers push apps to the platform. If you complete the procedure after apps have been pushed to the platform, you must start all the apps again in your deployment.

Prerequisites

The procedure section requires that you have the latest release of ASG Creator from the Cloud Foundry incubator repository on GitHub. For more information, see the About the ASG Creator Tool section of the App Security Groups topic.

Procedure

This procedure outlines how to apply ASGs that prevent apps running on your deployment from accessing internal TAS for VMs components.

Step 1: Determine your network layout

The procedure for securing your deployment with ASGs varies depending on your network layout. To determine your network layout:

Log in to Tanzu Operations Manager.
For each tile, click Assign AZs and Networks and record the selected Network that the tile is installed on.

Based on the information you gathered, determine which of the following network layouts you have:

Layout name	Layout description
One network	One network for Tanzu Operations Manager and the BOSH Director, TAS for VMs, and services. Caution You cannot secure your deployment with ASGs if you have this network layout. Because Operations Manager dynamically allocates IPs, they cannot be easily excluded in the case of a single network.
Two networks	One network for Tanzu Operations Manager and the BOSH Director. One network for TAS for VMs and Services.
Three networks	One network for Tanzu Operations Manager and the BOSH Director. One network for TAS for VMs. One network for all services.
Three or more networks	One network for Tanzu Operations Manager and the BOSH Director. One network for TAS for VMs. One network for each service.

If your network layout includes two or more networks, continue to Step 2: Ensure Access for TAS for VMs System Apps.

Step 2: Ensure access for TAS for VMs system apps

Applying the default ASG to the system org provides network access to TAS for VMs system apps without restrictions, which activates them to continue functioning properly after you perform Step 4: Remove the Deployment-wide Default ASG Binding. To apply the default ASG to the system org:

Bind the default ASG to the staging set in the system org by running:
```
cf bind-staging-security-group default_security_group system
```
Bind the default ASG to the running set in the system org by running:
```
cf bind-running-security-group default_security_group system
```

For more information about staging and running sets, see the ASG Sets section of the App Security Groups topic.

Step 3: Create new ASGs

This step outlines how to create ASGs that block apps from accessing TAS for VMs components and create any additional ASGs that allow apps to access the services they require.

Part A: Record CIDRs

To gather the CIDRs for each network in your deployment:

From the BOSH Director tile, click Create Networks within the Settings tab.
In the Networks section, expand each network in your deployment by clicking its name.
Record the CIDR for each network.

Part B: Create and bind ASGs that block network access

To create ASGs that block apps from sending traffic to the networks that host Tanzu Operations Manager, TAS for VMs, and, optionally, any installed services:

Create a config.yml containing the appropriate content for your network layout and replace the indicated values with the CIDRs you gathered:
- Two-network layout:
```
exclude:
- YOUR-OPS-MANAGER-CIDR
- YOUR-TAS-AND-SERVICES-CIDR
```
- Three-network layout:
  
  If you want to secure only the Tanzu Operations Manager and TAS for VMs components, you can remove the services CIDR from the exclude section.
```
exclude:
- YOUR-OPS-MANAGER-CIDR
- YOUR-TAS-CIDR
- YOUR-SERVICES-CIDR
```
- Three or more network layout:
  
  If you want to secure only the Tanzu Operations Manager and TAS for VMs components, you can remove the services CIDRs from the exclude section.
```
exclude:
- YOUR-OPS-MANAGER-CIDR
- YOUR-TAS-CIDR
- YOUR-SERVICE-CIDR-1
- YOUR-SERVICE-CIDR-2
etc...
```
To generate the public-networks.json and private-networks.json default files that contain your ASG rules, specify the location of the config.yml file as input, and run:
```
asg-creator create --config config.yml
```

Create the public-networks ASG by running:

cf create-security-group public-networks public-networks.json

Bind the ASG to the default staging set by running:
```
cf bind-staging-security-group public-networks
```
Bind the ASG to the default running set by running:
```
cf bind-running-security-group public-networks
```

Create the private-networks ASG by running:

cf create-security-group private-networks private-networks.json

Bind the ASG to the default staging set by running:
```
cf bind-staging-security-group private-networks
```
Bind the ASG to the default running set by running:
```
cf bind-running-security-group private-networks
```

To create and bind additional ASGs, see the Create ASGs and Bind ASGs sections of the App Security Groups topic.

Part C: Create and bind ASGs for service access

This part is only necessary if you blocked apps from a network that hosts services in the previous part.

If you did not block apps from a network that hosts services, proceed to Step 4: Remove the Default ASG.

Important In the two network layout, TAS for VMs and services share the same network. This means that each time you create an ASG that allows apps to access a new port and protocol within the network, you further expose the TAS for VMs component VMs. This is a limitation of a two network layout. For guidance on network topology, see Reference Architecture.

Now that you have created ASGs to secure the Tanzu Operations Manager, TAS for VMs, and service components, you can create additional ASGs that give apps access to the services they need.

For more information about creating and binding ASGs, see the Managing ASGs with the cf CLI and Typical ASGs sections of the App Security Groups topic.

Step 4: Remove the default ASG

Now that you have bound new ASGs to determine outbound traffic rules, you no longer need the default ASG bindings that allow apps to send traffic to any IP address. To remove the default ASG:

Unbind the default ASG from the staging set by running:

cf unbind-staging-security-group default_security_group

Unbind the default ASG from the running set by running:

cf unbind-running-security-group default_security_group

Step 5: Restart your apps

To apply the ASG changes, you must start all of the apps in your deployment again. To mitigate app downtime during the restart, VMware recommends a blue-green deployment strategy. For more information, see Using Blue-Green Deployment to Reduce Downtime and Risk.

To restart all of the apps in your deployment:

Work with developers to restart a few of their apps individually and test that they still work correctly with the new ASGs in place. If an app does not work as expected, you likely must create another ASG that allows the app to send traffic to a service it requires.

Note You do not have to restart the apps in the system org. To quickly roll back to the original overly permissive state, you can rebind the default_security_group ASG to the default-staging and default-running sets. You must then restart your apps to reapply the original ASGs
Restart the rest of the apps running on your deployment. You can use the app-restarter cf CLI plug-in to restart all apps in a particular space, org, or deployment.