Using Red Hat Service Interconnect to extend the reach of Ansible Automation Platform

Managing hosts within a third-party network using Red Hat Ansible Automation Platform (AAP) can present unique challenges due to security restrictions and several other obstacles, like strict policies that do not allow incoming connections to be established.

Additionally, setting up a VPN connection can introduce further complexities for organizations that are already dealing with complex IT environments. Many companies prefer to avoid the added administrative overhead associated with VPN.

This solution pattern introduces a secure, flexible and easy alternative to expose desired hosts running in protected environments, to be managed remotely by AAP using Red Hat Service Interconnect (RHSI).

Contributors: Fernando Giorgetti (Red Hat)


Solutions Patterns help you understand the art of the possible with Red Hat’s portfolio, and not intended to be used as is for production environments. You are welcome use any part of this solution pattern for your own workloads.

1. Use cases

Common use cases that can be addressed with this architecture are:

  • Extend your Ansible automation to reach hosts on private networks

  • Exposing TCP workloads accessible by a Linux or a Container endpoint, into a Kubernetes or OpenShift cluster

  • Access workloads running on a Kubernetes or OpenShift cluster as a local endpoint in your internal network using Red Hat Enterprise Linux, Podman or Docker, without exposing the Kubernetes or OpenShift resource publicly.

2. The story behind this solution pattern

Red Hat Ansible Automation Platform (AAP) is widely used to manage a variety of environments. In many occasions, a central AAP instance can be used to provide automation to multiple, and distinct, customers or partners, referred to in this solution pattern as a third-party network.

The organizations behind these third-party networks are independent and they need their internal network to remain secure and not exposed to external or public access, coming from the internet, but they need to allow a centralized AAP instance, owned by a trusted partner, to be able to maintain their server’s infrastructure.

Scenario

These organizations need an easy way to expose their target servers to be managed by the trusted partner, and they do not want to allocate extra resources or change their network infrastructure.

3. The Solution

With Red Hat Service Interconnect version 2, they can achieve that with minimal efforts, due to its declarative nature.

The partner that uses Red Hat Ansible Automation Platform (AAP) to maintain the third-party infrastructures, has its AAP instance running on an OpenShift cluster in the public cloud.

The partner will also prepare a Red Hat Service Interconnect site bundle to be installed into the third-party infrastructure, exposing their target servers into a specific namespace within their OpenShift cluster. An individual namespace will be used for each third-party network so that they’re isolated from other namespaces, being accessible only to the aap namespace, where the AAP instance is running.

With that, AAP can manage the third-party servers while keeping their hosts and network protected as all the traffic coming from AAP into their network will flow through Red Hat Service Interconnect, using secured mutual TLS authentication and encryption.