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.
While this can be accomplished with a VPN between the public cloud and the Globex data center, setting up a VPN can be hard 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.
The team chooses Red Hat Service Interconnect to create a secure Virtual Application Network (VAN) between these environments instead of implementing traditional VPNs which would require complex planning and management.
2. What is Red Hat Service Interconnect?
Red Hat Service Interconnect enables connectivity through a dedicated Layer 7 service network in the Open Systems Interconnection (OSI) model, by creating Virtual Application Networks (VANs) between distributed services and securing all interconnections with mutual TLS (mTLS).
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 the organization’s infrastructure and data protected.
Advantages of Layer 7 VAN over Traditional VPNs:
-
VAN exposes only services, not entire network layers, requiring fewer firewall rules whereas traditional VPNs connect entire clusters, requiring extensive and time consuming per-app firewall rules to achieve the same level of isolation as a VAN.
-
In a VAN, each site has its own Certificate Authority(CA), limiting security compromises
-
Only exposed services can be accessed in a VAN, preventing unauthorized lateral movement in case of a breach.
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.