Network peering on Red Hat Ansible Automation Platform on Microsoft Azure

Running Red Hat Ansible Automation Platform on Microsoft Azure is a great way to use Ansible Automation Platform in a managed environment. This allows you to use different components, such as the automation controller and Ansible automation hub, without maintaining infrastructure.

Red Hat performs most maintenance on the infrastructure so you don't have to. One thing you can manage yourself is the network. You have the ability to deploy a public Ansible Automation Platform, with a public-facing URL, or a private Ansible Automation Platform. You can also connect your Ansible Automation Platform instance to your own existing network. This means you can manage your private servers with Ansible. 

What do you need?

Ansible Automation Platform on Azure is deployed into an independently managed resource group with its own Azure virtual network (VNet).

When initially deployed, the Ansible Automation Platform on Azure’s VNet can only send requests to external networks over the public internet. To deploy Ansible Automation Platform on Azure to access resources over private networks, additional configurations must be set up, peering between the private VNets and Ansible Automation Platform on Azure’s managed application VNet. Azure VNets can be configured to enable private communication between multiple Azure VNets as well as private transit routes between Azure VNets and external VPN-routed networks. These VPN networks can be on-premises or on other clouds.

VNet peering

VNet peering enables you to connect virtual networks and route traffic between them privately. 

Sometimes, network limits or shared hub services prevent you from directly peering all VNets, so be sure you understand your environment before continuing.

Multiple networking topologies, such as direct peering or a hub-and-spoke model can exist in an environment. In this article, I provide an example demonstrating a connection between an AAP deployment and a hub-and-spoke network. Additional details on how to peer Ansible Automation Platform to other types of networks can be found in the official Ansible Automation Platform documentation.

In the hub-and-spoke example, I use an Azure Firewall as the main hub component that grants transitive peering between VNets. This can be done in many different ways with other kinds of Network Virtual Appliances (NVA), but the process generally looks like this:

1. Deploy Ansible Automation Platform on Azure
2. Create the peering connections
3. Deploy Azure Firewall
4. Configure user defined routes (UDR)

1. Deploy Ansible Automation Platform on Azure

First, deploy a public Ansible Automation Platform from the Azure Marketplace. Follow the instructions provided in the Ansible Automation Platform documentation.

In this example, I'm using a VNet with Ansible Automation Platform with a CIDR of 10.4.16.0/20. This VNet contains the following subnets:

• Cluster: 10.4.16.0/26
• Application gateway: 10.4.17.0/28
• Database: 10.4.19.0/28
• Private link: 10.4.18.0/28

Call this the AAP VNet.

Another VNet, acting as the hub, is located at 10.5.0.0/20. In this VNet, I've deployed a single Azure Firewall instance with forced tunneling configuration enabled. This allows transit peering between AAP VNet and the destination VNet.

Finally, I have a spoke VNet containing a single Virtual Machine. This VNet CIDR is 10.6.0.0/24.

This makes it possible to connect between Ansible Automation Platform in the VM in the spoke VNet and the AAP VNet. Azure Firewall is the main component granting transit network peering between VNets.

2. Create the peering connections

Once you have Ansible Automation Platform deployed and ready, you can create network peering between the AAP VNet and the Hub VNet. Because you're creating the peering from the Hub VNet, the details from “This virtual network” refers to the Hub VNet, and "Remote virtual network” refers to the AAP VNet.

For this example, I've enabled Traffic to remote virtual network and Traffic forwarded from remote virtual network. If you're using a VPN Gateway, the option changes to Virtual network gateway or Route Server.

This virtual network (Hub VNet):

• Peering link name: hub-to-aap
• Traffic to remote virtual network: Allow
• Traffic forwarded from remote virtual network: Allow
• Virtual network gateway or Route Server: None

Remote virtual network (AAP VNet):

• Peering link name: app-to-hub
• Virtual network deployment model: Resource manager
• Virtual network: vnet-aap111-eastus
• Traffic to remote virtual network: Allow
• Traffic forwarded from remote virtual network: Allow
• Virtual network gateway or Route Server: None

Repeat this process to create network peering to the spoke VNet.

Once both peerings are created, it takes a few seconds to show the Connected status from the Hub VNet:

This also creates the necessary peerings from AAP VNet and Spoke VNet to Hub VNet.

3. Deploy Azure Firewall

In this example, I'm using a single Azure Firewall instance with forced tunneling configuration enabled. As mentioned in Azure documentation, this is one of the options to allow traffic between spoke VNets in a hub-and-spoke topology. In this scenario, I'm using user-defined-routes (UDR) to force spoke traffic to be sent to Azure Firewall, so it acts as a router at the hub.

For detailed instructions, read the Azure documentation for deploying an Azure Firewall instance. The only change to make after creating the Azure Firewall is to allow traffic from Ansible Automation Platform to the VM on port 22. Create a rule collection for this:

• Name: myRuleCollection
• Rule collection type: Network
• Priority: 100
• Rule collection action: Allow
• Rule collection group: DefaultNetworkRuleCollectionGroup
• Rules:
  • Name: aaptospoke
  • Source type: IP Address
  • Source: 10.4.16.0/20
  • Protocol: Any
  • Destination Ports: 22
  • Destination: 10.6.0.0/24

Once the Azure Firewall instance with forced tunneling configuration is available and a policy that allows traffic is created, it's time to configure the UDR.

4. Configure user-defined-routes (UDR)

As a final step, you must create the necessary network routes (Azure UDR) to grant traffic between AAP VNet and the Spoke VNet. Read the UDR documentation for more information about how to configure routes.

Ansible Automation Platform deploys a route table alongside all its other components. This route table is already attached to the AKS or Cluster subnet of Ansible Automation Platform, so you only have to add the routes that are needed. Because the Ansible Automation Platform is connected to the Spoke VNet through network peering, you can read the Red Hat documentation about configuring the routes for more information.

Navigate to the Route Tables service in Azure. The one you're looking for has a unique name in the form of aks-agentpool-<id>-routetable.

Next, add the whole CIDR of the spoke VNet and configure the Next hop type as Virtual Appliance. Because you're using Azure Firewall to allow transit traffic between AAP VNet and the Spoke VNet through the Hub VNet, you must configure the Next hop IP address with the private IP of the Azure Firewall instance. If using any kind of different NVA (Network Virtual Appliance), then you must change this setting accordingly.

Here are my settings:

• Destination type: IP Addresses
• Destination IP addresses/CIDR ranges: 10.6.0.0/24
• Next hop type: Virtual appliance
• Next hop address: 10.5.1.4

You also need to create a new route table in your Spoke VNet, and attach it to the subnet where the VM is deployed. After that, the route can be added as needed:

• Destination type: IP Addresses
• Destination IP addresses/CIDR ranges: 10.4.16.0/20
• Next hop type: Virtual appliance
• Next hop address: 10.5.1.4

With this, the VM deployed in the Spoke VNet should be reachable from Ansible Automation Platform. 

Making connections

With this setup, private network connectivity is granted between the Ansible Automation Platform instance and any spoke network in the hub-and-spoke model. It's as easy as adding the necessary routes and, in the case of using Azure firewall, adding the necessary policies.