IPsec N/S with policy based IPsec routing

1. Proposed title of this feature request
IPsec N/S with policy based IPsec routing

2. What is the nature and description of the request?
TELCOSTRAT-93 will provide a mechanism to secure incoming and outgoing traffic to the cluster (either via Ingress/Egress in OpenShift or direct host access) using IPSec.

Some Telco partners and customers require more fine grained control than provided by TELCOSTRAT-93 and the ability to secure different traffic using different IPsec tunnels based on configured policies.

For example securing:

• Direct host layer 3 traffic using IPsec tunnel A via northbound secGW A to the Telco Operator's remote management systems.
• OpenShift API traffic using IPsec tunnel B via northbound secGW B to the Telco Operator's network management systems.
• Pod foo's primary interface Ingress/Egress traffic via tunnel C via northbound secGW C to the Telco Operator's application management systems.
• Operator bar's primary interface Ingress/Egress traffic via tunnel D via northbound secGW D to the Telco Operator's external software repository.
• Platform and application logs forwarded via tunnel E via northbound secGW E to the Telco Operator's log management systems.
• etc.

Telco partners require this policy based IPsec routing capability for all OpenShift cluster topologies (SNO, SNO+worker, all flavours of MNO). For SNO+worker and MNO cluster topologies there is no requirement to aggregate IPsec traffic from multiple nodes in the cluster.

Configuration of this policy based IPsec routing capability should be possible either directly (e.g. CRD) as well as via ZTP/GitOps.

Further details of the partner's use case is documented here [Red Hat Employees only].

3. Why does the customer need this? (List the business requirements here)

Telco Operators segregate different systems and capabilities, that communicate with OCP clusters and workloads running on those clusters, across different physical/logical locations each with their own IPsec terminating security gateways, resulting in the need to secure traffic from OCP clusters to those locations/systems/peers using multiple IPSec tunnels to avoid carrying that traffic directly over unsecured/untrusted network segments and to allow traffic to be transported over the most direct network path.

4. List any affected packages or components.