anchor.diff:  
   ### <a id='config-traffic'></a>Network Traffic Rules ###
   
  -Administrators can configure rules to govern container network traffic. These rules can prevent system access from external networks and between internal components, and restrict applications from establishing connections over the virtual network interface.
  +Administrators configure rules to govern container network traffic. 
  +This is how containers send traffic outside of CF and receive traffic from outside, the Internet.
  +These rules can prevent system access from external networks and between internal components
  +and determine if apps can establish connections over the virtual network interface.
   
   Administrators configure these rules at two levels: 
   
   * Application Security Groups (ASGs) apply network traffic rules at the container level. <%=vars.app_sec_groups_link%>
  -* [Network Properties](#network-properties) of cells apply network traffic rules at the host VM level.
  -
  -#### <a id='network-properties'></a>Host-level Network Properties ####
  -
  -Operators can configure the `allow_networks` and `deny_networks` parameters for cells to restrict communication between system components and applications. 
  -
  -To configure host-level network properties, edit the following properties in your Diego manifest and redeploy:
  -
  -```
  -  garden.deny_networks:
  -    description: "List of CIDR blocks to which containers will be denied access."
  -    default: []
  -
  -  garden.allow_networks:
  -    description: "List of CIDR blocks to which containers will be allowed access (applied after deny)."
  -    default: []
  -```
  -
  -<p class="note"><strong>Note</strong>: ASGs provide a greater degree of security than host-level network properties. ASGs enable you to more securely restrict application outbound traffic to predefined routes. ASGs also overwrite any host-level configurations.</p> 
  -
  -<%= vars.container_security2 %>
  +* Container networking policies determine app-to-app communication. 
  +  Within CF, apps can communicate directly with each other, but the containers are isolated from outside CF.
  +  For information about administering container network policies, 
  +  see [Administering Container Networking](../adminguide/container-networking.html).  
   
   ## <a id='security'></a>Container Security###
   
  
positive.code: CF mitigates against container breakout and denial of service attacks in the following ways:
  
  * CF uses the full set of [Linux namespaces](http://manpages.ubuntu.com/manpages/wily/man7/namespaces.7.html) (IPC, Network, Mount, PID, User, UTS) to provide isolation between containers running on the same host. The User namespace is not used for privileged containers.
  * In unprivileged containers, CF maps UID/GID 0 (root) inside the container user namespace to a different UID/GID on the host to prevent an application from inheriting UID/GID 0 on the host if it breaks out of the container. 
  	* CF uses the same UID/GID for all containers.
      * CF maps all UIDs except UID 0 to themselves. CF maps UID 0 inside the container namespace to `MAX_UID-1` outside of the container namespace.
      * Container Root does not grant Host Root permissions.
  
negative.code: 
  Garden has two container types: unprivileged and privileged. Currently, CF runs all application instances and staging tasks in unprivileged containers by default. This measure increases security by eliminating the threat of root escalation inside the container.
  
  Formerly, CF ran apps based on Docker images in unprivileged containers, and buildpack-based apps and staging tasks in privileged containers. CF ran apps based on Docker images in unprivileged containers because Docker images come with their own root filesystem and user, so CF could not trust the root filesystem and could not assume that the container user process would never be root. CF ran build-pack based apps and staging tasks in privileged containers because they used the cflinuxfs2 root filesystem and all processes were run as the unprivileged user `vcap`.
  
  Although all application instances and staging tasks now run by default in unprivileged containers, operators can override these defaults by customizing their Diego deployment manifest and redeploying.
  
  * To enable privileged containers for buildpack-based apps, set the `capi.nsync.diego_privileged_containers` property to `true` in the Diego manifest.
  * To enable privileged containers for staging tasks, set the `capi.stager.diego_privileged_containers` property to `true` in the Diego manifest.
  
  ### <a id='hardening'></a> Hardening
  