anchor.diff:  
   [[admin-guide-controlling-egress-traffic]]
   == Controlling Egress Traffic
  -As an {product-title} cluster administrator, you can control egress traffic
  -using either a xref:admin-guide-deploying-an-egress-router-service[router] or
  -xref:admin-guide-limit-pod-access-egress[firewall] methods.
  -
  -[[admin-guide-limit-pod-access-egress-router]]
  -=== Limiting Pod Access with an Egress Router
  -
  -The {product-title} egress router runs a service that redirects traffic to a
  -specified remote server, using a private source IP address that is not used for
  -anything else. The service allow pods to talk to servers that are set up
  -to only allow access from whitelisted IP addresses.
  -
  -[[admin-guide-limit-pod-access-important-deployment-considerations]]
  -==== Important Deployment Considerations
  -
  -The Egress router adds a second IP address and MAC address to the node's primary
  -network interface. If you are not running {product-title} on bare metal, you may
  -need to configure your hypervisor or cloud provider to allow the additional
  -address.
  -
  -*Red Hat OpenStack Platform*
  -
  -If you are deploying {product-title} on Red Hat OpenStack Platform, you need to
  -whitelist the IP and MAC addresses on your Openstack environment, otherwise
  -link:https://access.redhat.com/solutions/2803331[communication will fail]:
  -
  -----
  -neutron port-update $neutron_port_uuid \
  -  --allowed_address_pairs list=true \
  -  type=dict mac_address=<mac_address>,ip_address=<ip_address>
  -----
  -
  -*Red Hat Enterprise Virtualization*
  -
  -If you are using
  -link:https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Virtualization/3.2/html/Administration_Guide/Red_Hat_Enterprise_Virtualization_Manager_configuration_options_explanations_limitations_and_best_practices.html[Red
  -Hat Enterprise Virtualization], you should set
  -`EnableMACAntiSpoofingFilterRules` to `false`.
  -
  -*VMware vSphere*
  -
  -If you are using VMware vSphere, follow VMware's
  -link:http://pubs.vmware.com/vsphere-4-esxi-installable-vcenter/index.jsp?topic=/com.vmware.vsphere.esxi_server_config.doc_40_u1/esx_server_config/securing_an_esx_configuration/c_securing_virtual_switch_ports.html[Securing
  -Virtual Switch Ports] and
  -link:http://pubs.vmware.com/vsphere-4-esxi-installable-vcenter/index.jsp?topic=/com.vmware.vsphere.esxi_server_config.doc_40_u1/esx_server_config/securing_an_esx_configuration/c_forged_transmissions.html[Forged
  -Transmissions] guidance.
  -
  -[[admin-guide-deploying-an-egress-router-pod]]
  -==== Deploying an Egress Router Pod
  -
  -.Example Pod Definition for an Egress Router
  -====
  -----
  -apiVersion: v1
  -kind: Pod
  -metadata:
  -  name: egress-1
  -  labels:
  -    name: egress-1
  -  annotations:
  -    pod.network.openshift.io/assign-macvlan: "true"
  -spec:
  -  containers:
  -  - name: egress-router
  -ifdef::openshift-enterprise[]
  -    image: openshift3/ose-egress-router
  -endif::openshift-enterprise[]
  -ifdef::openshift-origin[]
  -    image: openshift/origin-egress-router
  -endif::openshift-origin[]
  -    securityContext:
  -      privileged: true
  -    env:
  -    - name: EGRESS_SOURCE <1>
  -      value: 192.168.12.99
  -    - name: EGRESS_GATEWAY <2>
  -      value: 192.168.12.1
  -    - name: EGRESS_DESTINATION <3>
  -      value: 203.0.113.25
  -  nodeSelector:
  -    site: springfield-1 <4>
  -----
  -<1> IP address on the node subnet reserved by the cluster administrator for use by
  -this pod.
  -<2> Same value as the default gateway used by the node itself.
  -<3>  Connections to the pod are redirected to 203.0.113.25, with a source IP
  -address of 192.168.12.99
  -<4> The pod will only be deployed to nodes with the label site *springfield-1*.
  -====
  -
  -The `pod.network.openshift.io/assign-macvlan annotation` creates a Macvlan
  -network interface on the primary network interface, and then moves it into the
  -pod's network name space before starting the *egress-router* container.
  -
  -[NOTE]
  -====
  -Preserve the the quotation marks around `"true"`. Omitting them will result in
  -errors.
  -====
  -
  -The pod contains a single container, using the
  -ifdef::openshift-enterprise[]
  -*openshift3/ose-egress-router*
  -endif::openshift-enterprise[]
  -ifdef::openshift-origin[]
  -*openshift/origin-egress-router*
  -endif::openshift-origin[]
  -image, and that container is run privileged so that it can configure the Macvlan
  -interface and set up `iptables` rules.
  -
  -The environment variables tell the *egress-router* image what addresses to use; it
  -will configure the Macvlan interface to use `EGRESS_SOURCE` as its IP address,
  -with `EGRESS_GATEWAY` as its gateway.
  -
  -NAT rules are set up so that connections to any TCP or UDP port on the
  -pod's cluster IP address are redirected to the same port on
  -`EGRESS_DESTINATION`.
  -
  -If only some of the nodes in your cluster are capable of claiming the specified
  -source IP address and using the specified gateway, you can specify a
  -`nodeName` or `nodeSelector` indicating which nodes are acceptable.
  -
  -[[admin-guide-deploying-an-egress-router-service]]
  -==== Deploying an Egress Router Service
  -
  -Though not strictly necessary, you normally want to create a service pointing to
  -the egress router:
  -
  -====
  -----
  -apiVersion: v1
  -kind: Service
  -metadata:
  -  name: egress-1
  -spec:
  -  ports:
  -  - name: http
  -    port: 80
  -  - name: https
  -    port: 443
  -  type: ClusterIP
  -  selector:
  -    name: egress-1
  -----
  -====
  -
  -Your pods can now connect to this service. Their connections are redirected to
  -the corresponding ports on the external server, using the reserved egress IP
  -address.
  +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]]
  -=== Limiting Pod Access with Egress Firewall
  -
  -As an {product-title} cluster administrator, you can use egress policy to limit
  -the external addresses that some or all pods can access from within the cluster, so that:
  +=== 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.
  
positive.code: - 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>`.
  
  [CAUTION]
  ====
  
negative.code: `20.21.22.23`. Then, {product-title} will take up to 30 minutes to adapt to
  these DNS updates.
  
  . Use the JSON file to create an EgressNetworkPolicy object:
  +
  ----
  # oc create -f <policy>.json
  ----
  
  [[admin-guide-limit-pod-access-egress-router]]
  === Using an Egress Router to Allow External Resources to Recognize Pod Traffic
  
  The {product-title} egress router runs a service that redirects traffic to a
  specified remote server, using a private source IP address that is not used for
  anything else. The service allows pods to talk to servers that are set up
  to only allow access from whitelisted IP addresses.
  
  [[admin-guide-limit-pod-access-important-deployment-considerations]]
  ==== Important Deployment Considerations
  
  The Egress router adds a second IP address and MAC address to the node's primary
  network interface. If you are not running {product-title} on bare metal, you may
  need to configure your hypervisor or cloud provider to allow the additional
  address.
  
  *Red Hat OpenStack Platform*
  
  If you are deploying {product-title} on Red Hat OpenStack Platform, you need to
  whitelist the IP and MAC addresses on your Openstack environment, otherwise
  link:https://access.redhat.com/solutions/2803331[communication will fail]:
  
  ----
  neutron port-update $neutron_port_uuid \
    --allowed_address_pairs list=true \
    type=dict mac_address=<mac_address>,ip_address=<ip_address>
  ----
  
  *Red Hat Enterprise Virtualization*
  
  If you are using
  link:https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Virtualization/3.2/html/Administration_Guide/Red_Hat_Enterprise_Virtualization_Manager_configuration_options_explanations_limitations_and_best_practices.html[Red
  Hat Enterprise Virtualization], you should set
  `EnableMACAntiSpoofingFilterRules` to `false`.
  
  *VMware vSphere*
  
  If you are using VMware vSphere, follow VMware's
  link:http://pubs.vmware.com/vsphere-4-esxi-installable-vcenter/index.jsp?topic=/com.vmware.vsphere.esxi_server_config.doc_40_u1/esx_server_config/securing_an_esx_configuration/c_securing_virtual_switch_ports.html[Securing
  Virtual Switch Ports] and
  link:http://pubs.vmware.com/vsphere-4-esxi-installable-vcenter/index.jsp?topic=/com.vmware.vsphere.esxi_server_config.doc_40_u1/esx_server_config/securing_an_esx_configuration/c_forged_transmissions.html[Forged
  Transmissions] guidance.
  
  [[admin-guide-deploying-an-egress-router-pod]]
  ==== Deploying an Egress Router Pod
  
  . Create a pod configuration using the following:
  +
  .Example Pod Definition for an Egress Router
  ====
  ----
  apiVersion: v1
  kind: Pod
  metadata:
    name: egress-1
    labels:
      name: egress-1
    annotations:
      pod.network.openshift.io/assign-macvlan: "true" <1>
  spec:
    containers:
    - name: egress-router
  ifdef::openshift-enterprise[]
      image: openshift3/ose-egress-router
  endif::openshift-enterprise[]
  ifdef::openshift-origin[]
      image: openshift/origin-egress-router
  endif::openshift-origin[]
      securityContext:
        privileged: true
      env:
      - name: EGRESS_SOURCE <2>
        value: 192.168.12.99
      - name: EGRESS_GATEWAY <3>
        value: 192.168.12.1
      - name: EGRESS_DESTINATION <4>
        value: 203.0.113.25
    nodeSelector:
      site: springfield-1 <5>
  ----
  <1> The `pod.network.openshift.io/assign-macvlan annotation` creates a Macvlan
  network interface on the primary network interface, and then moves it into the
  pod's network name space before starting the *egress-router* container. Preserve
  the the quotation marks around `"true"`. Omitting them will result in errors.
  <2> An IP address from the physical network that the node itself is on and is
  reserved by the cluster administrator for use by this pod.
  <3> Same value as the default gateway used by the node itself.
  <4> The external server that to direct traffic to. Using this example,
  connections to the pod are redirected to 203.0.113.25, with a source IP address
  of 192.168.12.99.
  <5> The pod will only be deployed to nodes with the label `site=springfield-1`.
  ====
  
  . Create the pod using the above definition:
  +
  ----
  $ oc create -f <pod_name>.json
  ----
  +
  To check to see if the pod has been created:
  +
  ----
  oc get pod <pod_name>
  ----
  
  . Ensure other pods can find the pod's IP address by creating a service to point to the egress router:
  +
  ====
  ----
  apiVersion: v1
  kind: Service
  metadata:
    name: egress-1
  spec:
    ports:
    - name: http
      port: 80
    - name: https
      port: 443
    type: ClusterIP
    selector:
      name: egress-1
  ----
  ====
  +
  Your pods can now connect to this service. Their connections are redirected to
  the corresponding ports on the external server, using the reserved egress IP
  address.
  
  The pod contains a single container, using the
  ifdef::openshift-enterprise[]
  *openshift3/ose-egress-router*
  endif::openshift-enterprise[]
  ifdef::openshift-origin[]
  *openshift/origin-egress-router*
  endif::openshift-origin[]
  image, and that container is run privileged so that it can configure the Macvlan
  interface and set up `iptables` rules.
  
  The environment variables tell the *egress-router* image what addresses to use; it
  will configure the Macvlan interface to use `EGRESS_SOURCE` as its IP address,
  with `EGRESS_GATEWAY` as its gateway.
  
  NAT rules are set up so that connections to any TCP or UDP port on the
  pod's cluster IP address are redirected to the same port on
  `EGRESS_DESTINATION`.
  
  If only some of the nodes in your cluster are capable of claiming the specified
  source IP address and using the specified gateway, you can specify a
  `nodeName` or `nodeSelector` indicating which nodes are acceptable.
  
  [[admin-guide-manage-pods-egress-router-failover]]
  ==== Enabling Failover for Egress Router Pods
  
  Using a replication controller, you can ensure that there is always one copy of the egress router pod in order to prevent downtime.
  
  . Create a replication controller configuration file using the following:
  +
  ====
  ----
  apiVersion: v1
  kind: ReplicationController
  metadata:
    name: egress-demo-controller
  spec:
    replicas: 1 <1>
    selector:
      name: egress-demo
    template:
      metadata:
        name: egress-demo
        labels:
          name: egress-demo
        annotations:
          pod.network.openshift.io/assign-macvlan: "true"
      spec:
        containers:
        - name: egress-demo-container
          image: openshift/origin-egress-router
          env:
          - name: EGRESS_SOURCE
            value: 192.168.12.99
          - name: EGRESS_GATEWAY
            value: 192.168.12.1
          - name: EGRESS_DESTINATION
            value: 203.0.113.25
          securityContext:
            privileged: true
        nodeSelector:
          site: springfield-1
  ----
  <1> Ensure `replicas` is set to `1`, because only one pod can be using a given
  `EGRESS_SOURCE` value at any time. This means that only a single copy of the
  router will be running, on a node with the label `site=springfield-1`.
  ====
  
  . Create the pod using the definition:
  +
  ----
  $ oc create -f <replication_controller>.json
  ----
  
  . To verify, check to see if the replication controller pod has been created:
  +
  ----
  oc describe rc <replication_controller>
  ----
  
  [[admin-guide-manage-pods-limit-bandwidth]]
  == Limiting the Bandwidth Available to Pods
  
  