Chapter 4. Connecting to Red Hat Ansible Automation Platform
When network peering is complete and your Azure routing configuration is established, you can choose how your team accesses Ansible Automation Platform through your Azure network configuration.
4.1. Access details
Regardless of whether Ansible Automation Platform was deployed with public or private access, a set of DNS records is created. The DNS records are created so that Ansible Automation Platform can be issued a valid TLS certificate for your deployment and to enable easy access to your applications.
To view a list of the URLs for the Ansible Automation Platform applications, navigate to the Parameters and Outputs page of the Azure Marketplace managed application listing for your deployment.
4.2. Public Deployments
If you selected public access when you deployed Ansible Automation Platform on Microsoft Azure, you can access the Ansible Automation Platform application URLs over the public internet from a browser.
4.3. Private deployments
If you selected private access when deploying Ansible Automation Platform on Microsoft Azure, then the DNS record issued to the Red Hat Ansible Automation Platform on Microsoft Azure application points to a private address within the CIDR block selected when the managed application was deployed. You must configure access to this address after you have created network peering.
The configuration and access method that you choose to connect to Ansible Automation Platform on Microsoft Azure depends on how your organization manages Azure infrastructure. Your Azure administrators must determine the right model for your organization and configure the setup for you.
The following are the most common options:
4.3.1. Azure hosted virtual machine
A straightforward way to configure access for a small set of users to access private network resources on Azure networks is to create a jumpbox VM in a perimeter network (DMZ VNet) that users can remotely log into from the public internet. The jumpbox VM requires workstation features such as a GUI and browser.
Users can remotely log into the publicly accessible virtual machine from on-premises machines through VNC, RDP, or other screen-sharing protocols.
To access the Ansible Automation Platform web UIs on the Azure private network, users navigate to the URLs using the browser on the jumpbox VM.
The DMZ VNet is connected to other Azure VNets through network peering, with routing rules established to send network traffic to the Ansible Automation Platform VNet.
The following diagram shows the topology for an example configuration of private network access via an Azure virtual machine.
- For more information about perimeter (DMZ) networks, refer to Perimeter Networks in the Microsoft Azure Cloud Adoption Framework documentation.
- For more information about jumpboxes, refer to About Azure bastion host and jumpboxes in the Microsoft Azure Cloud Adoption Framework documentation.
4.3.2. VPN
If your organization requires that many users access Ansible Automation Platform over a private connection, or if your organization already uses VPNs or direct connections with Azure, then this approach might be suitable.
In this configuration, your on-premises infrastructure is connected to Azure through a Network Application Gateway and has routing rules that can enable access to Ansible Automation Platform to any connected computer on the local network. The VNet connected to the Virtual Network Gateway is connected to other Azure VNets through network peering, with routing rules established to send network traffic to the Ansible Automation Platform VNet.
With this configuration, users can access Ansible Automation Platform through the application URLs as if they were using the public access approach.
4.3.3. SSH tunnel
When VPN is not an option and your local users are more technical, the SSH tunnel approach is a secure alternative that enables users to access Ansible Automation Platform from a browser on a local machine.
To implement this access model, create a lightweight Linux-based SSH server in a DMZ network, similar to the Azure Hosted Virtual Machine method. The SSH server does not require any workstation features, because it simply acts as a proxy between a user’s local machine and Ansible Automation Platform on Microsoft Azure.
Each user must be configured as an SSH user on the server. Users can then establish an SSH tunnel from the local machine to the SSH server to route traffic for Ansible Automation Platform on Microsoft Azure.
This approach is easier to implement on Linux and macOS host machines, but can be accomplished on Windows.
Update your local hosts file so that the Ansible Automation Platform URLs route traffic to your local machine rather than the private IP that DNS records are configured with. Add the following line to your hosts file:
127.0.0.1 controller.<your_AAPonAzure_instance>.az.ansiblecloud.comThe following example shows the line in a hosts file:
## # 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.<your_AAPonAzure_instance>.az.ansiblecloud.comAs a user with root privileges, run the
sshcommand to establish an SSH tunnel.In the example below,
SSH_server_IPrepresents the IP address of the SSH server in your DMZ.sudo ssh azureuser@<SSH_server_IP> -i ~/.ssh/id_ssh_key -N -f -L 443:controller.<your_AAPonAzure_instance>.az.ansiblecloud.com:443
The
-Lflag makes your local system route traffic for the automation controller URL over port 443 (HTTPs).NoteYou must use port 443 on both sides of the routing path. Using a different port on the local machine causes some Ansible Automation Platform features to not function properly.
When the SSH tunnel is established and your Azure routing is configured, you can access the automation controller URL from your local browser at https://controller.<your_AAPonAzure_instance>.az.ansiblecloud.com.
