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 OKD cluster.
A pod cannot reach specified internal subnets or hosts outside the OKD cluster.
A pod can connect to only specific external hosts.
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 configure an egress firewall policy by creating an EgressFirewall custom resource (CR) object. The egress firewall matches network traffic that meets any of the following criteria:
An IP address range in CIDR format
A port number
A protocol that is one of the following protocols: TCP, UDP, and SCTP
If your egress firewall includes a deny rule for
0.0.0.0/0, access to your OKD API servers is blocked.
To ensure that pods can continue to access the OKD API servers, you must include the IP address range that the API servers listen on in your egress firewall rules, as in the following example:
namespace: <namespace> (1)
cidrSelector: <api_server_address_range> (2)
cidrSelector: 0.0.0.0/0 (3)
|The namespace for the egress firewall.
|The IP address range that includes your OKD API servers.
|A global deny rule prevents access to the OKD API servers.
To find the IP address for your API servers, run
oc get ep kubernetes -n default.
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 firewall 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 EgressFirewall object.
A maximum of one EgressFirewall object with a maximum of 8,000 rules can be defined per project.
Violating any of these restrictions results in a broken egress firewall for the project, and may cause all external network traffic to be dropped.
Matching order for egress firewall policy rules
The egress firewall 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.