IBM Cloud Docs
Ensuring isolation between Satellite management functions and workload functions

Ensuring isolation between Satellite management functions and workload functions

A key aspect of the IBM Cloud Framework for Financial Services is to separate user workloads from system management functions and isolate security functions from nonsecurity functions. The network infrastructure of the Satellite location can be used to provide physical and logical separation between the Satellite management control plane and your workloads.

Network flow rule design should follow the IBM Cloud Framework for Financial Services's information flow guidelines by using a "deny by default" approach.

Before you begin

  1. Complete the work for account setup and management.
  2. Complete Satellite location setup.

Identify network areas for control plane hosts and workload hosts

  1. Place control plane hosts into a separate network segment. Control plane hosts support various management and security-related components of the Satellite location. To facilitate effective network flow restrictions within the Satellite location, it is recommended to place control plane hosts into a separate network segment (whether physical or virtual) that can enable clear identification of source or destination of the network flows related to control plane functionality. The control plane hosts can be deployed to different physical locations, but the address space they are assigned to should provide an easy way to identify this group of hosts (for example, CIDR blocks).
  2. Designate a separate network segment for each group of Satellite hosts assigned to Red Hat OpenShift on IBM Cloud workload clusters. Satellite hosts that are assigned to Red Hat OpenShift on IBM Cloud workload clusters (workload hosts) should use their own network segments that would enable network flow control and monitoring between workload hosts, control plane, and other components outside of the Satellite location. It is recommended to designate a separate network segment (virtual subnet, VLAN, or a similar entity) for each group of Satellite hosts assigned to the same workload cluster.
  3. Ensure network flows between network segments that are allocated for control plane hosts and workload hosts are allowed without restrictions. Therefore, in general, the hosts within the control plane or same workload cluster need to have unrestricted network connections to each other, the network flow control is applied to traffic that crosses the boundaries of a particular group of hosts that are assigned to the control plane or same workload cluster. The host network requirements provide detailed specifications for connectivity requirements between Satellite location hosts.
  4. Make sure that the selected network infrastructure can provide performance compatible with the host latency requirements.

Design an addressing plan for control and workload segments

  1. Define network address range (subnet or CIDR block) for control plane hosts.
  2. Define network address range (subnet or CIDR block) for the workload hosts of each Red Hat OpenShift on IBM Cloud cluster in the Satellite location.

Configure network flow rules to restrict network traffic for control plane

The following rules for control plane hosts must be implemented within the networking infrastructure (virtual or physical) provided by the operator of the Satellite location.

  1. Allow inbound flows for control plane hosts (API endpoints, TCP 30000 - 32767) from management plane within your environment. For example, to support bastion or CI/CD tools.
  2. Allow bidirectional flows between control plane hosts and workload hosts of the same Satellite location.
  3. Allow outbound flows to workload hosts of the same Satellite location.
  4. If Satellite Link location endpoint is configured to enable connection from IBM Cloud to a resource within the Satellite location, allow the outbound flow from control plane hosts to the resource used in the location endpoint for each such endpoint.
  5. If Satellite Link cloud endpoints are used by components other than workload hosts in the Satellite location (for example, to access IBM Cloud IAM services from an application deployed outside of the Satellite location), allow inbound flow to the control plane hosts from the resource that requires access the cloud endpoint that uses the destination port listed in the endpoint address attribute.
  6. Ensure that control plane hosts are configured to allow outbound access to IBM Cloud public endpoints. For more information, see Accessing external resources from the Satellite location.

Configure network flow rules for workload hosts

The following rules for workload hosts must be implemented within the networking infrastructure (virtual or physical) provided by the operator of the Satellite location.

  1. Allow inbound network flows to workload hosts from management resources within your environment, such as a bastion host in your management plane. It is recommended to use networking components capable of controlling Level 7 traffic to limit access to services such as Red Hat OpenShift on IBM Cloud web console based on the FQDN of the request. A combination of network rules and an HTTP proxy can be used as well.
  2. Allow bidirectional network flows between workload hosts and control plane hosts of the same Satellite location.
  3. Identify and allow network flows to other application resources within the environment that is required by the deployed workloads. For example, databases that are not deployed on the same workload service.
  4. Identify and allow network flows to other services deployed in the Satellite location (for example, another Red Hat OpenShift on IBM Cloud cluster) if required by the workload application architecture.
  5. Identify and allow the ingress network flows from the edge plane that is used to expose the workload services to application consumers (for example, load balancers).
  6. Allow outbound network flows to service endpoints in management plane that is needed for logging and monitoring.
  7. Ensure that workload hosts have outbound access to IBM Cloud public endpoints. For more information, see Accessing external resources.

(Optional) Configure virtual network flow rules within Red Hat OpenShift on IBM Cloud

  1. Configure virtual network flow rules within Red Hat OpenShift on IBM Cloud. In addition to the network flow controls implemented within the IaaS layer of the Satellite location, you can use virtual networking features of Red Hat OpenShift on IBM Cloud to control network flows within and into your cluster. You can use Kubernetes network policies or Calico network policies to define network flow restrictions for each workload deployed on your Red Hat OpenShift on IBM Cloud cluster.

Next steps