PCF installs with a default ASG that allows apps running on your deployment to send traffic to almost any IP address. This means apps are not blocked from initiating connections to most network destinations unless an administrator takes action to update the ASGs with a more restrictive policy.

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 procedure below, which includes these steps:

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 Ops Manager.

2

Ensure Access for PCF System Apps: Bind the default ASG to the system org so that PCF 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:

Pivotal recommends that you complete this procedure directly after installing PCF, prior to developers pushing apps to the platform. If you complete the procedure after apps have been pushed to the platform, you must restart all the apps in your deployment.

Run the following command to generate the default public-networks.json and private-networks.json files that contain your ASG rules, specifying the location of the config.yml file as input:

$ asg-creator create --config config.yml

Create the public-networks ASG by running the following command:

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

Bind the ASG to the default staging set:

$ cf bind-staging-security-group public-networks

Bind the ASG to the default running set:

$ cf bind-running-security-group public-networks

Create the private-networks ASG by running the following command:

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

Bind the ASG to the default staging set:

$ cf bind-staging-security-group private-networks

Bind the ASG to the default running set:

$ cf bind-running-security-group private-networks

Note: You can create and bind additional ASGs by following the procedures in Create ASGs and Bind ASGs.

Part C: Create and Bind ASGs for Service Access

Note: 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.

WARNING: In the two network layout, PAS 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 PAS component VMs. This is a limitation of a two network layout. For guidance on network topology, see Reference Architectures.

Now that you have created ASGs to secure the Ops Man, PAS, and service components, work with developers to create additional ASGs that give apps access to the services they need.

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.

Unbind the default ASG from the staging set:

$ cf unbind-staging-security-group default_security_group

Unbind the default ASG from the running set:

$ cf unbind-running-security-group default_security_group

Step 5: Restart your Apps

To apply the ASG changes, you must restart all of the apps in your deployment. To mitigate app downtime during the restart, Pivotal recommends a blue-green deployment strategy.

Notes: You do not need to restart the apps in the system org.

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: To quickly roll back to the original overly-permissive state, you can re-bind the default_security_group ASG to the default-staging and default-running sets. You must then restart your apps to re-apply the original ASGs.

Restart the rest of the apps running on your deployment. Optionally, you can use the app-restarter cf CLI plugin to restart all apps in a particular space, org, or deployment.