MicroShift is Developer Preview software only.
For more information about the support scope of Red Hat Developer Preview software, see Developer Preview Support Scope.Chapter 2. Using a firewall
Firewalls are not required in Red Hat build of MicroShift, but using a firewall can prevent undesired access to the Red Hat build of MicroShift API.
2.1. About network traffic through the firewall
When using a firewall, you must explicitly allow the following OVN-Kubernetes traffic when the firewalld
service is running:
- CNI pod to CNI pod
- CNI pod to Host-Network pod Host-Network pod to Host-Network pod
- CNI pod
- The Kubernetes pod that uses the CNI network
- Host-Network pod
-
The Kubernetes pod that uses host network Install and configure the
firewalld
service by using the following procedures.
Red Hat build of MicroShift pods must have access to the internal CoreDNS component and API servers.
2.2. Installing the firewalld service
Use the following procedure to install and run the firewalld
service for Red Hat build of MicroShift.
Procedure
To install the
firewalld
service, run the following command:$ sudo dnf install -y firewalld
To initiate the firewall, run the following command:
$ sudo systemctl enable firewalld --now
2.3. Required firewall settings
An IP address range for the cluster network must be enabled during firewall configuration. You can use the default values or customize the IP address range. If you choose to customize the cluster network IP address range from the default 10.42.0.0/16
setting, you must also use the same custom range in the firewall configuration.
IP Range | Firewall rule required | Description |
---|---|---|
10.42.0.0/16 | No | Host network pod access to other pods |
169.254.169.1 | Yes | Host network pod access to Red Hat build of MicroShift API server |
The following are examples of commands for settings that are mandatory for firewall configuration:
Example commands
Configure host network pod access to other pods:
$ sudo firewall-cmd --permanent --zone=trusted --add-source=10.42.0.0/16
Configure host network pod access to services backed by Host endpoints, such as the Red Hat build of MicroShift API:
$ sudo firewall-cmd --permanent --zone=trusted --add-source=169.254.169.1
2.4. Using optional port settings
The Red Hat build of MicroShift firewall service allows optional port settings.
Procedure
To add customized ports to your firewall configuration, use the following command syntax:
$ sudo firewall-cmd --permanent --zone=public --add-port=<port number>/<port protocol>
Table 2.2. Optional ports Port(s) Protocol(s) Description 80
TCP
HTTP port used to serve applications through the OpenShift Container Platform router.
443
TCP
HTTPS port used to serve applications through the OpenShift Container Platform router.
5353
UDP
mDNS service to respond for OpenShift Container Platform route mDNS hosts.
30000-32767
TCP
Port range reserved for NodePort services; can be used to expose applications on the LAN.
30000-32767
UDP
Port range reserved for NodePort services; can be used to expose applications on the LAN.
6443
TCP
HTTPS API port for the Red Hat build of MicroShift API.
The following are examples of commands used when requiring external access through the firewall to services running on Red Hat build of MicroShift, such as port 6443 for the API server, for example, ports 80 and 443 for applications exposed through the router.
Example commands
Configuring a port for the Red Hat build of MicroShift API server:
$ sudo firewall-cmd --permanent --zone=public --add-port=6443/tcp
Configuring ports for applications exposed through the router:
$ sudo firewall-cmd --permanent --zone=public --add-port=80/tcp
$ sudo firewall-cmd --permanent --zone=public --add-port=443/tcp
2.5. Allowing network traffic through the firewall
You can allow network traffic through the firewall by first configuring the IP address range with either default or custom values, and then allow internal traffic from pods through the network gateway by inserting the DNS server.
Procedure
Set the default values or a custom IP address range. After setting the IP address range, allow internal traffic from the pods through the network gateway.
To set the IP address range:
To configure the IP address range with default values, run the following command:
$ sudo firewall-offline-cmd --permanent --zone=trusted --add-source=10.42.0.0/16
Alternatively, you can configure the IP address range with custom values by running the following command:
$ sudo firewall-offline-cmd --permanent --zone=trusted --add-source=<custom IP range>
To allow internal traffic from pods through the network gateway, run the following command:
$ sudo firewall-offline-cmd --permanent --zone=trusted --add-source=169.254.169.1
2.5.1. Applying firewall settings
To apply firewall settings, use the following one-step procedure:
Procedure
After you have finished configuring network access through the firewall, run the following command to restart the firewall and apply settings:
$ sudo firewall-cmd --reload
2.6. Verifying firewall settings
After you have restarted the firewall, you can verify your settings by listing them.
Procedure
To verify rules added in the default public zone, such as ports-related rules, run the following command:
$ sudo firewall-cmd --list-all
To verify rules added in the trusted zone, such as IP-range related rules, run the following command:
$ sudo firewall-cmd --zone=trusted --list-all
2.7. Known firewall issue
-
To avoid breaking traffic flows with a firewall reload or restart, execute firewall commands before starting Red Hat build of MicroShift. The CNI driver in Red Hat build of MicroShift makes use of iptable rules for some traffic flows, such as those using the NodePort service. The iptable rules are generated and inserted by the CNI driver, but are deleted when the firewall reloads or restarts. The absence of the iptable rules breaks traffic flows. If firewall commands have to be executed after Red Hat build of MicroShift is running, manually restart
ovnkube-master
pod in theopenshift-ovn-kubernetes
namespace to reset the rules controlled by the CNI driver.
Additional resources