Network and firewall requirements

Introduction

It is best practice to restrict network traffic by using firewalls. In particular with Red Hat OpenShift Container Platform, pods can talk to servers on the internet by default. This abets attacks where malicious code is sideloaded from the internet. Therefore, it is recommended to restrict any internet access from within the Red Hat OpenShift Container Platform cluster to required sites. For more information, see Configuring your firewall.

The following list covers solely the requirements of IBM Storage Scale container native and IBM Storage Scale CSI.

IBM Storage Scale uses several communication channels that need to be opened in the corresponding firewalls otherwise some or all functions might be broken. The channels can be categorized into three major groups:

1. Communication between pods inside a Red Hat OpenShift Container Platform cluster.
   • Communication inside Red Hat OpenShift Container Platform cluster is subject to firewall rules on worker node's kernels and/or network policies that are defined in Red Hat OpenShift Container Platform.
2. Communication between Red Hat OpenShift Container Platform cluster and storage cluster.
   • Communication with the storage cluster is in addition subject to the firewall that sits on the load-balancer in front of Red Hat OpenShift Container Platform.
3. Communication between Red Hat OpenShift Container Platform cluster and servers on the internet.
   • Communication with the internet is subject to the boundary firewall of the data center and the boundary firewall of the intranet.

Communication between pods

IBM Storage Scale container native core pods use two network interfaces, an "admin" and a "daemon" interface. The "admin" interface is used for monitoring and management, while the "daemon" interface is used for file system I/O. In a default configuration, the pod is created with hostNetwork: true and both networks use the Kubernetes node internal network on the host and is exposed to the pod.

When using the default host networking, the networking requirements that are outlined must be satisfied and opened across the Kubernetes node internal network.

It is recommended to use Container Network Interface (CNI) driver for the daemon network instead of host networking. This allows for better security and isolation. If using CNI, only Core Pod Daemon Network Requirements need to be satisfied and the Admin network will use the default Red Hat OpenShift Pod SDN Network. For more information, see Container network interface (CNI) configuration.

Core pod admin network requirements

The following network requirements must be met when hostNetwork: true on the pod specification. This is the default deployment method when CNI is not used. These are only needed to be open between nodes within the local IBM Storage Scale container native cluster.

Core pod daemon network requirements

Those are identical to the requirements for communication with a storage cluster. For more information, see Daemon network requirements.

Communication with storage cluster

Daemon network requirements

The following list of ports and protocols are used to communicate between all nodes within the IBM Storage Scale container native cluster and between nodes in any configured remote storage clusters. Each node acts as a server that may initiate connections to any other node. Ensure the list of ports and protocols are open for both inbound and outbound packet flows.

Ephemeral port ranges

Ephemeral ports are used by the GPFS Policy Engine, which is used by the CSI snapshot and compression features. When tscCmdAllowRemoteConnections=yes is configured in the Cluster CR, ephemeral port ranges are also used for communication and compatibility with remote clusters.

If ephemeral ports are configured on the remote storage cluster, ensure that they are also configured in the Cluster CR for the IBM Storage Scale container native deployment.

For more information on how to set ephemeral port ranges, see Ephemeral port range.

REST API access

Pod network encapsulates the requirement that IBM Storage Scale container native operator and IBM Storage Scale CSI operator and driver require the ability to reach the storage cluster GUI nodes REST API. These respective pods use the default pod network and schedule to any node selected.

Name resolution between IBM Storage Scale container native and storage cluster

The IBM Storage Scale container native core pods require name resolution to all storage cluster nodes, specifically the node's daemon node name. If these names cannot be configured in the environment's domain name service (DNS), then host aliases can be added in the cluster CR .spec.daemon.hostAliases. This configuration adds these host aliases to the internal DNS managed by IBM Storage Scale container native and applies only to name resolution performed by the IBM Storage Scale container native core pods.

Communication with the internet

Container registries

The images of IBM Storage Scale container native containers are located in the IBM Cloud Registry.

To access the IBM Cloud Container Registry by using the domains cp.icr.io and icr.io, you must add the following hostnames to your firewall rules:

• dd0.icr.io
• dd2.icr.io
• dd4.icr.io
• dd6.icr.io

Users that are located in China must also allow the following hostnames:

• dd1-icr.ibm-zh.com
• dd3-icr.ibm-zh.com
• dd5-icr.ibm-zh.com
• dd7-icr.ibm-zh.com

Egress to these sites is required unless the cluster is configured in airgap mode. For more information, see Disconnected installs.

Callhome

If callhome function is enabled, ingress and egress need to be open to esupport.ibm.com (129.42.0.0/18).

For more information, see Firewall recommendations for call home.

Encryption

If encryption is configured on the file system, egress on the following ports is required for each service to function:

For more information, see Firewall recommendations for IBM Security Key Lifecycle Manager.