This is a cache of https://docs.openshift.com/container-platform/4.3/networking/openshift_sdn/configuring-egress-firewall.html. It is a snapshot of the page at 2024-11-21T01:33:20.865+0000.
Configuring an <strong>egress</strong> firewall for a project - OpenShift SDN default CNI network provider | Networking | OpenShift Container Platform 4.3
    Soon, all Red Hat OpenShift documentation will only be available on docs.redhat.com, the official location of all Red Hat product documentation. Get familiar with the updated experience today!
  1. Documentation
    2. history
×

Configuring an egress firewall to control access to external IP addresses

How an egress firewall works in a project

As a cluster administrator, you can use an egress firewall to limit the external hosts that some or all Pods can access from within the cluster. An egress firewall supports the following scenarios:

  • A Pod can only connect to internal hosts and cannot initiate connections to the public Internet.

  • A Pod can only connect to the public Internet and cannot initiate connections to internal hosts that are outside the OpenShift Container Platform cluster.

  • A Pod cannot reach specified internal subnets or hosts outside the OpenShift Container Platform cluster.

  • A Pod can connect to only specific external hosts.

You configure an egress firewall policy by creating an egressNetworkPolicy Custom Resource (CR) object and specifying an IP address range in CIDR format or by specifying a DNS name. For example, you can allow one project access to a specified IP range but deny the same access to a different project. Or you can restrict application developers from updating from Python pip mirrors, and force updates to come only from approved sources.

You must have OpenShift SDN configured to use either the network policy or multitenant modes to configure egress firewall policy.

If you use network policy mode, egress policy is compatible with only one policy per namespace and will not work with projects that share a network, such as global projects.

egress firewall rules do not apply to traffic that goes through routers. Any user with permission to create a Route CR object can bypass egress network policy rules by creating a route that points to a forbidden destination.

Limitations of an egress firewall

An egress firewall has the following limitations:

  • No project can have more than one egressNetworkPolicy object.

  • A maximum of 1 egressNetworkPolicy object with a maximum of 50 rules can be defined per project.

  • The default project cannot use egress network policy.

  • When using the OpenShift SDN default Container Network Interface (CNI) network provider in multitenant mode, the following limitations apply:

    • Global projects cannot use an egress firewall. You can make a project global by using the oc adm pod-network make-projects-global command.

    • Projects merged by using the oc adm pod-network join-projects command cannot use an egress firewall in any of the joined projects.

Violating any of these restrictions results in broken egress network policy for the project, and may cause all external network traffic to be dropped.

Matching order for egress network policy rules

The egress network policy rules are evaluated in the order that they are defined, from first to last. The first rule that matches an egress connection from a Pod applies. Any subsequent rules are ignored for that connection.

How Domain Name Server (DNS) resolution works

If you use DNS names in any of your egress firewall policy rules, proper resolution of the domain names is subject to the following restrictions:

  • Domain name updates are polled based on the TTL (time to live) value of the domain returned by the local non-authoritative servers.

  • The Pod must resolve the domain from the same local name servers when necessary. Otherwise the IP addresses for the domain known by the egress firewall controller and the Pod can be different. If the IP addresses for a host name differ, the egress firewall might not be enforced consistently.

  • Because the egress firewall controller and Pods asynchronously poll the same local name server, the Pod might obtain the updated IP address before the egress controller does, which causes a race condition. Due to this current limitation, domain name usage in egressNetworkPolicy objects is only recommended for domains with infrequent IP address changes.

The egress firewall always allows Pods access to the external interface of the node that the Pod is on for DNS resolution.

If you use domain names in your egress firewall policy and your DNS resolution is not handled by a DNS server on the local node, then you must add egress firewall rules that allow access to your DNS server’s IP addresses. if you are using domain names in your Pods.

egressNetworkPolicy custom resource (CR) object

The following YAML describes an egressNetworkPolicy CR object:

apiVersion: network.openshift.io/v1
kind: egressNetworkPolicy
metadata:
  name: <name> (1)
spec:
  egress: (2)
    ...
1 Specify a name for your egress firewall policy.
2 Specify a collection of one or more egress network policy rules as described in the following section.

egressNetworkPolicy rules

The following YAML describes an egress firewall rule object. The egress key expects an array of one or more objects.

egress:
- type: <type> (1)
  to: (2)
    cidrSelector: <cidr> (3)
    dnsName: <dns-name> (4)
1 Specify the type of rule. The value must be either Allow or Deny.
2 Specify a value for either the cidrSelector key or the dnsName key for the rule. You cannot use both keys in a rule.
3 Specify an IP address range in CIDR format.
4 Specify a domain name.

Example egressNetworkPolicy CR object

The following example defines several egress firewall policy rules:

apiVersion: network.openshift.io/v1
kind: egressNetworkPolicy
metadata:
  name: default-rules (1)
spec:
  egress: (2)
  - type: Allow
    to:
      cidrSelector: 1.2.3.0/24
  - type: Allow
    to:
      dnsName: www.example.com
  - type: Deny
    to:
      cidrSelector: 0.0.0.0/0
1 The name for the policy object.
2 A collection of egress firewall policy rule objects.

Creating an egress firewall policy object

As a cluster administrator, you can create an egress firewall policy object for a project.

If the project already has an egressNetworkPolicy object defined, you must edit the existing policy to make changes to the egress firewall rules.
Prerequisites

  • A cluster that uses the OpenShift SDN default Container Network Interface (CNI) network provider plug-in.

  • Install the OpenShift CLI (oc).

  • You must log in to the cluster as a cluster administrator.

Procedure

  1. Create a policy rule:

    1. Create a <policy-name>.yaml file where <policy-name> describes the egress policy rules.

    2. In the file you created, define an egress policy object.

  2. Enter the following command to create the policy object:

    $ oc create -f <policy-name>.yaml -n <project>

    In the following example, a new egressNetworkPolicy object is created in a project named project1:

    $ oc create -f default-rules.yaml -n project1
    Example output
    egressnetworkpolicy.network.openshift.io/default-rules created

  3. Optional: Save the <policy-name>.yaml so that you can make changes later.