Building a secure service network with Red Hat Service Interconnect - Intro

In this module you discover how to build a service network to connect disparate services across different environments using Red Hat Service Interconnect.

1. Business and Technical Context

As mentioned in the introduction module of the workshop, Globex went through a first modernization phase for their retail web application, moving from a legacy monolith to a containerized application. The Globex retail application runs on OpenShift in the public cloud. However, for a number of technical and regulatory reasons, the database of the Globex retail application is still running on-premise in one of Globex’s data centers.

The challenge for Globex is now to enable the retail application to connect to the database. For obvious reasons, Globex doesn’t want to expose the database over the public internet, so a private, secure link needs to be setup between the OpenShift instance on the public cloud and the Globex data center. This can be accomplished with a VPN between the public cloud and the Globex data center. However a VPN can be hard to set up, and requires deep networking expertise. Developers also need to request the network admins and go through a time taking approval process for the VPNs to be setup.

Red Hat Service Interconnect on the other hand creates a dedicated layer 7 service network and is a lot easier to set up. It allows application developers to establish secure interconnection with other services and applications in different environments without relying on network specialists. With Service Interconnect developers can now create secure virtual application networks without the cumbersome overhead, complexity and delays of traditional connectivity solutions.

2. What is Red Hat Service Interconnect?

Red Hat Service Interconnect enables application and service connectivity across different environments through layer 7 addressing and routing. Using a simple command line interface, interconnections are created in a matter of minutes, avoiding extensive networking planning, and overhead. All interconnections between environments use mutual TLS to keep your organization’s infrastructure and data protected.

3. Setting up Red Hat Service Interconnect

In the next chapter, you will be guided through setting up a service network between the Globex retail application, running on OpenShift in the public cloud (AWS in this case) and the Globex database, running on OpenShift on another cloud provider.

The concept of an on-premise deployment is challenging to simulate in a lab environment. This is why we opted to have the database running on OpenShift in an isolated namespace. Pods deployed in that namespace can communicate with other pods in the same namespace, and they create connections with the outside world (egress), both inside as outside of the cluster. On the other hand they cannot be reached by pods in other namespaces in the cluster, or by external services. This effectively mimics a situation of an on-prem deployment where egress is allowed, but ingress not. However, Red Hat Service Interconnect is not limited to service networks between (instances of) OpenShift, but can equally well be leveraged to connect deployments running on premise (deployed on OpenShift or Kubernetes, on virtual machines or on bare metal) with services running in the cloud.

Proceed to the instructions for this module.