anchor.diff:  ---
  -title: Application Security Groups
  +title: App Security Groups
   owner: Security
   ---
   
  -
  -
  -This topic provides an overview of Application Security Groups (ASGs) in <%= vars.product_full %>, and describes how to manage and administer them. Many of the steps below require the [Cloud Foundry Command Line Interface](../cf-cli/install-go-cli.html) (cf CLI) tool.
  +This topic provides an overview of App Security Groups (ASGs) in <%= vars.product_full %>, and describes how to manage and administer them. Many of the steps below require the [Cloud Foundry Command Line Interface](../cf-cli/install-go-cli.html) (cf CLI) tool.
   <%= vars.asg_first_time %>
   
  -## <a id='introduction'></a> About Application Security Groups
  -
  -Application Security Groups (ASGs) are a collection of egress rules that
  -specify the protocols, ports, and IP address ranges where app or task instances
  -send traffic.
  -
  -ASGs define **allow** rules, and their order of evaluation is unimportant
  -when multiple ASGs apply to the same space or deployment.
  -The platform sets up rules to filter and log outbound network traffic from app and task instances.
  -ASGs apply to both buildpack-based and Docker-based apps and tasks.
  +## <a id='introduction'></a> Overview
  +
  +App Security Groups (ASGs) are a collection of egress rules that specify the protocols, ports, and IP address ranges where app or task instances send traffic.
  +
  +ASGs define **allow** rules, and their order of evaluation is unimportant when multiple ASGs apply to the same space or deployment. The platform sets up rules to filter and log outbound network traffic from app and task instances. ASGs apply to both buildpack-based and Docker-based apps and tasks.
   
   ### <a id='staging-running'></a> Staging and Running ASGs
   
   Administrators can define a `staging` ASG for app and task staging, and a `running` ASG for app and task runtime.
   
  -When apps or tasks begin staging, they require traffic rules permissive enough to allow them to pull resources from the network.
  -A running app or task no longer needs to pull resources, so traffic rules can be more restrictive and secure.
  -To distinguish between these two security requirements, administrators can define a `staging` ASG for app and task staging with more permissive rules, and a `running` ASG for app and task runtime with less permissive rules.
  +When apps or tasks begin staging, they require traffic rules permissive enough to allow them to pull resources from the network. A running app or task no longer needs to pull resources, so traffic rules can be more restrictive and secure. To distinguish between these two security requirements, administrators can define a `staging` ASG for app and task staging with more permissive rules, and a `running` ASG for app and task runtime with less permissive rules.
   
   ### <a id='types'></a> Platform-Wide and Space-Scoped ASGs
   
  -To provide granular control when securing a deployment, administrators can
  -assign platform-wide ASGs that apply to all app and task instances for the entire deployment, or space-scoped ASGs that apply only to apps and tasks in a particular space.
  +To provide granular control when securing a deployment, administrators can assign platform-wide ASGs that apply to all app and task instances for the entire deployment, or space-scoped ASGs that apply only to apps and tasks in a particular space.
   
   In environments with both platform-wide and space-specific ASGs, the ASGs for a particular space combine with the platform ASGs to determine the rules for that space.
   
   ### <a id='simplifying'></a> Simplifying ASGs with a Services Subnet
   
  -ASGs can be complicated to configure correctly, especially when the specific IP
  -addresses listed in a group change.
  -
  -To simplify securing a deployment while still allowing apps reach external
  -services, operators can deploy the services into a subnet that is separate from
  -their <%= vars.product_short %> deployment, then create ASGs for the apps that whitelist those service subnets, while denying access to any VM hosting other apps.
  +ASGs can be complicated to configure correctly, especially when the specific IP addresses listed in a group change.
  +
  +To simplify securing a deployment while still allowing apps reach external services, operators can deploy the services into a subnet that is separate from their <%= vars.product_short %> deployment, then create ASGs for the apps that allow those service subnets, while denying access to any VM hosting other apps.
   
   For examples of typical ASGs, see the <a href="#typical-groups">Typical Application Security Groups</a> section below.
   
  
positive.code: 
  ### <a id='public-networks-example'></a> Public Networks
  
  Apps often require public network connectivity to retrieve app dependencies, or
  to integrate with services available on public networks.
  Example app dependencies include public Maven repositories, NPM, RubyGems, and
  Docker registries.
  
  <p class='note'><strong>Note</strong>: You should exclude IaaS metadata endpoints, such as <code>169.254.169.254</code>, because the metadata endpoint can expose sensitive environment information to untrusted apps. The <code>public_networks</code> example below accounts for this recommendation.
  </p>
  
  Example `public_networks` ASG:
  
  
negative.code: 
  ### <a id='dns-example'></a> DNS
  
  To resolve hostnames to IP addresses, apps require DNS server connectivity, which typically use port 53. Administrators should create or update a `dns` ASG with appropriate rules. Administrators can further restrict the DNS servers to specific IP addresses or ranges of IP addresses.
  
  Example `dns` ASG:
  
  