anchor.diff:  
   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 applications based on Docker images in unprivileged containers, and buildpack-based applications and staging tasks in privileged containers. CF ran applications 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 applications and staging tasks in privileged containers because they used the cflinuxfs2 root filesystem and all processes were run as the unprivileged user `vcap`.
  +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 applications, set the `capi.nsync.diego_privileged_containers` property to `true` in the Diego manifest.
  +* 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
  
positive.code: 
  ### <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 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 %>
  
  ## <a id='security'></a>Container Security###
  
  
negative.code:     <strong>Note</strong>: CF does not support a RedHat Enterprise Linux OS stemcell. This is due to an inherent security issue with the way RedHat handles user namespacing and container isolation.
  </p>
  
  ## <a id='networking'></a>Inbound and Outbound Traffic from CF
  
  ### <a id='net-overview'></a>Networking Overview ###
  
  A host VM has a single IP address. 
  If you configure the deployment with the cluster on a VLAN, as recommended, 
  then all traffic goes through the following levels of network address translation, as shown in the diagram below.
  
  * <strong>Inbound</strong> requests flow from the load balancer through the router to the host cell, then into the application container. The router determines which application instance receives each request.
  
  