anchor.diff:  - A pod cannot reach specified internal subnets/hosts that it should have no
   reason to contact.
   
  -For example, you can configure projects with different egress policies, allowing
  -`<project A>` access to a specified IP range, but denying the same access to
  -`<project B>`.
  +You can configure projects to have different egress policies. For example,
  +allowing `<project A>` access to a specified IP range, but denying the same
  +access to `<project B>`. Or restrict application developers from updating from
  +(Python) pip mirrors, and forcing updates to only come from desired sources.
   
   [CAUTION]
   ====
  
positive.code: edit the ones you create in their project. There are also several other
  restrictions on where `EgressNetworkPolicy` can be created:
  
  . The `default` project (and any other project that has been made global via
  `oadm pod-network make-projects-global`) cannot have egress policy.
  
  . If you merge two projects together (via `oadm pod-network join-projects`),
  then you cannot use egress policy in _any_ of the joined projects.
  
  . No project may have more than one egress policy object.
  
  Violating any of these restrictions will result in broken egress policy for the
  project, and may cause all external network traffic to be dropped.
  
  [[admin-guide-config-pod-access]]
  ==== Configuring Pod Access Limits
  
  To configure pod access limits, you must use the `oc` command or the REST API.
  You can use `oc [create|replace|delete]` to manipulate `EgressNetworkPolicy`
  objects. The *_api/swagger-spec/oapi-v1.json_* file has API-level details on how
  the objects actually work.
  
  To configure pod access limits:
  
  . Navigate to the project you want to affect.
  . Create a JSON file for the pod limit policy:
  +
  ----
  # oc create -f <policy>.json
  ----
  . Configure the JSON file with policy details. For example:
  +
  ----
  {
  
negative.code: 
  [[admin-guide-controlling-egress-traffic]]
  == Controlling Egress Traffic
  As an {product-title} cluster administrator, you can control egress traffic in two ways:
  
  xref:admin-guide-limit-pod-access-egress[Firewall]::
  Using an egress firewall allows you to enforce the acceptable outbound traffic
  policies, so that specific endpoints or IP ranges (subnets) are the only
  acceptable targets for the dynamic endpoints (pods within {product-title}) to
  talk to.
  
  xref:admin-guide-limit-pod-access-egress-router[Router]::
  Using an egress router allows you to create identifiable services to send
  traffic to a specific destination, ensuring an external destination treats
  traffic as though it were coming from a known source. This helps with security,
  because it allows you to secure an external database so that only specific pods
  in a namespace can talk to a service (the egress router), which proxies the
  traffic to your database.
  
  
  [[admin-guide-limit-pod-access-egress]]
  === Using an Egress Firewall to Limit Access to External Resources
  
  As an {product-title} cluster administrator, you can use egress firewall policy
  to limit the external addresses that some or all pods can access from within the
  cluster, so that:
  
  - A pod can only talk to internal hosts, and cannot initiate connections to the
  public Internet.
  