Thank you to Hicham Mourad and Scott Harwell for co-authoring this blog.

Introduction

In this blog series, we will continue discussing the deployment of Red Hat Ansible Automation Platform on Microsoft Azure.

The first blog covered the deployment process as well as how to access a Red Hat Ansible Automation Platform on Azure deployment that was deployed using the “Public” access option.

This blog we’ll cover how to access the managed application when it’s deployed using the “Private” access option.

 

Connecting to Red Hat Ansible Automation Platform on Microsoft Azure

There are three ways you can access Red Hat Ansible Automation Platform on Azure if you selected “Private” access.

• An Azure hosted virtual machine (VM)
• Azure VPN or Direct Connect
• SSH Tunnel

Let’s assume that you have already configured network peering between the Red Hat Ansible Automation Platform on Azure deployment, on the Azure network and your existing Azure Virtual Networks.  Network peering is an Azure action for connecting two or more networks on Azure that route traffic to resources across those networks.  See Microsoft Azure documentation for more information on network peering types.

 

Access Details

Regardless of whether you selected public or private during the deployment, a set of DNS records are always created.  The URLs for Red Hat Ansible Automation Platform on Azure are available in the Azure Marketplace managed application listing for your deployment under the “Parameters and Outputs” section.

This DNS record is created so that Red Hat Ansible Automation Platform on Azure can be issued a valid TLS certificate for your deployment and to simplify access.

 

Public Deployments

As noted in the first blog of this series, if “Public” access was selected when Red Hat Ansible Automation Platform on Azure was deployed, then you will be able to directly access the web UIs over the public internet by navigating to the URL with your browser, easy peasy.

 

Private Deployments

If “Private” access was selected when Red Hat Ansible Automation Platform on Azure was deployed, then you will likely need to take action after creating network peering.  The DNS record issued to the public application will point to a private Class C network address 192.168.0.68.  Additional configuration is required for the URL and IP address to be accessible from your web browser.

The access method and configuration that your organization chooses to connect to Red Hat Ansible Automation Platform on Azure will likely depend on how your organization manages the Azure infrastructure.  Your Azure administrator(s) will need to determine the proper access method for your organization and perform the necessary setup.  

Earlier, we noted some available access options.  Let’s get into some additional details around each of the three options we listed.

 

Azure Hosted Virtual Machine

Likely, the easiest way to configure access for a small set of users is to create a jump box virtual machine in a DMZ virtual network (VNET) where users can remote into the VM from the public internet to gain access to private network resources on Azure networks.  The VM would need to have workstation features (a GUI and web browser installed in the case of Linux), since users will leverage the web browser on this machine in order to navigate to Red Hat Ansible Automation Platform on Azure web UIs.  

The DMZ would be connected to other Azure VNETs through network peering with routing rules established to send network traffic for 192.168.0.0/24 to the Red Hat Ansible Automation Platform on Azure VNET.  

PCs from office locations can remote into the publicly accessible virtual machine through VNC, RDP, or other screen-sharing protocols (whichever you configure on the VM).  Then, using a web browser on the virtual machine, you may enter the Red Hat Ansible Automation Platform on Azure UI URLs to access the platform on the private network.  Here’s a high level overview diagram of what this looks like.

 

Azure VPN or Direct Connect

If your organization requires that many users connect to Red Hat Ansible Automation Platform on Azure over a private connection, or if your organization already has established VPNs or direct connections with Azure cloud, then this approach is likely suitable for your requirements.

In this case, your on-premises infrastructure is connected to Azure through a network application gateway and has routing rules that can enable access to Red Hat Ansible Automation Platform on Azure to any connected computer on the local network.  The VNET connected to the virtual network gateway would be connected to other Azure VNETs through network peering with routing rules established to send network traffic for 192.168.0.0/24 to the Red Hat Ansible Automation Platform on Azure VNET.

With this configuration, users would not need to perform any extra configuration; they would be able to access Red Hat Ansible Automation Platform on Azure through the application URLs as if they were using the public access approach.  Here’s a high level overview diagram of what this looks like.

SSH Tunnel

When VPN isn’t an option, and your users are more technically inclined, the SSH tunnel approach can offer a secure alternative that allows users to use their local browser to access Red Hat Ansible Automation Platform on Azure.  This approach is usually easiest on Linux and macOS host machines, but can also be accomplished on Windows.

In this access model, a lightweight Linux SSH server can be placed into a DMZ network similar to the Azure Hosted Virtual Machine method.  However, no workstation features are required for the server.  This server will simply act as a proxy between a user’s local machine and Red Hat Ansible Automation Platform on Azure.

Each user needs to be configured as an SSH user on the server.  Once completed, the users can establish an SSH tunnel from their local machine to the SSH server to route traffic for Red Hat Ansible Automation Platform on Azure.

The first step is to update your local hosts file so that the Red Hat Ansible Automation Platform on Azure URL(s) route traffic to your local host (your PC) instead of the private IP that DNS records are configured with.

 ##
# Host Database
#
# localhost is used to configure the loopback interface
# when the system is booting.  Do not change this entry.
##
127.0.0.1	      localhost
255.255.255.255    broadcasthost
::1                localhost

127.0.0.1      controller.<yourAAPonAzureInstance>.az.ansiblecloud.com

Note: The last line in the image above is what you would add to your hosts file.

Next, you can establish the SSH tunnel.  In the example below, the IP address is the address of the SSH server in your DMZ.  The -L flag will tell your local system to route traffic for the automation controller URL over port 443 (HTTPs).

sudo ssh [email protected] -i ~/.ssh/id_ssh_key -N -f -L 443:controller.<yourAAPonAzureInstance>.az.ansiblecloud.com:443

Note: At this time, port 443 must be used on both sides of the routing path.  Using a different port on the local machine will cause some Red Hat Ansible Automation Platform on Azure features to not function properly.  This procedure does require root level access on the local machine.

If the SSH tunnel has been established and your Azure routing is configured properly, then you should be able to access the automation controller URL in your local browser at:

https://controller.<yourAAPonAzureInstance>.az.ansiblecloud.com

Here’s a high level overview diagram of what this looks like.

Happy automating!

 

What can I do next?

Here are a few resources to get started: 

• To learn more about Red Hat Ansible Automation Platform on Azure, visit the following site. 
• Try a hands-on self-paced lab of Red Hat Ansible Automation Platform on Azure.
• Visit other hands-on self-paced lab(s) on Red Hat Ansible Automation Platform.
• Check out the Red Hat Ansible Automation Platform on Azure documentation.
• Would you like to receive updates on Red Hat Ansible Automation Platform on Azure? Sign up here.