Chapter 5. Networking and application access
When Ansible Automation Platform from GCP Marketplace is deployed, it is installed into an isolated VPC and cannot be accessed. The following instructions describe how to connect the VPC used by Ansible Automation Platform from GCP Marketplace to your existing GCP network. When connected, you must determine how your users connect to Ansible Automation Platform.
There are many ways to enable this connectivity such as VPNs, Google Cloud Interconnect, or bastion servers for private network access. You can also expose the platform with public internet access using GCP services such as a Load Balancer.
How your organization configures application access on GCP is outside the scope of Red Hat’s guidelines and support for Ansible Automation Platform from GCP Marketplace. For further information, see Securely connecting to VMs for guidelines on these topics.
5.1. Networking options
The network topology of Ansible Automation Platform from GCP Marketplace includes several configurable network segments that can be changed to fit into your organization’s network requirements.
The deployment creates a new VPC and subnet that are not accessible from the public internet, or by using an existing VPC network. You must provide access to the application as described in Networking and Application Access.
Consider your existing network configurations when specifying the following network ranges below. Ensure that each range does not overlap with any other specified here, and does not overlap with existing ranges in your network. Each range should exist within a private network class.
Application Subnet Range
The network CIDR defining the subnet range used by the custom VPC deployed by the offering. Must be a minimum /24 segment and must be in the private network range (192.168 or 10.0).
Default: 192.168.240.0/24
Cloud SQL Peering Network Range
The network CIDR defines the network segment used to peer the GCP CloudSQL network with the application subnet deployed by the offering. Must be a /24 segment. The /24 segment range is a requirement of GCP CloudSQL network peering configuration.
Default: 192.168.241.0/24
Filestore Peering Network Range
Ansible Automation Platform from GCP Marketplace uses GCP Filestore service to share configuration files between multiple automation controller and automation hub VMs provisioned as part of the deployment. This network CIDR range defines the peer network that is used by the offering to peer between the GCP Filestore network and the custom VPC application subnet of the offering. Must be a minimum /29 segment.
Default: 192.168.243.0/29
Load Balancer Proxy Subnet Range
Ansible Automation Platform from GCP Marketplace is deployed using GCP’s native cloud capabilities to provide a scalable and reliable installation. As part of the Ansible Automation Platform from GCP Marketplace deployment topology two load balancers are deployed in front of the automation hub and automation controller VMs. All traffic is directed at these load balancers and is proxied to the available backend VMs. The deployment takes advantage of GCP’s native load balancing support enabling the customer to add additional ports (https) to the load balancers to capture and forward requests onto the backend VMs. This also provides request balancing and session tracking for better reliability. As part of the load balancer deployment, GCP requires creation of a special proxy network where GCP natively handles the redirection of requests to the backend VMs. This special proxy network is not used within Ansible Automation Platform from GCP Marketplace for any other purpose than GCP’s load balancer’s proxy network requirement. A /24 segment is required.
Default: 192.168.242.0/24
Controller Internal Load Balancer IP Address
This is the static IP Address assigned to the automation controller Load Balancer. This address must be within the Application Subnet Range segment.
Default: 192.168.240.20
Hub Internal Load Balancer IP Address
This is the static IP Address assigned to the automation hub Load Balancer. This address must be within the Application Subnet Range segment.
Default: 192.168.240.21
5.2. Network peering options
Many networking configurations to access the platform are possible, but the following configurations have been validated to work with Ansible Automation Platform from GCP Marketplace.
While every effort has been made to align with Google Cloud Platform’s documentation for this content, there may be a drift in accuracy over time. Use GCP documentation as the source of information regarding networking topics for GCP.
5.3. VPC peering
VPC Peering is required for Ansible Automation Platform to access resources that reside on private VPCs or where transit routing between Google Cloud Platform and your on-premises network(s) exists. It offers the ability to directly connect different networks within your GCP infrastructure. VPCs are individually connected to one another with no other routing hops between them. VPC deployments omit access from the public internet by default.
This is also the deployment model for the GCP architecture used by Ansible Automation Platform from GCP Marketplace.
This is a simple peering model and is useful when connecting several networks.
Complex peering can be configured, but routing can become more complex over time.
When VPC peering and routing are configured, you can access Ansible Automation Platform through a VM on a connected VPC subnet, or directly if your organization has a transit routing setup between GCP and your local networks.
When two or more networks are peered, Google performs automated actions to assist with routing, but can perform routable updates to enable traffic flow within your GCP infrastructure.
Prerequisites
Before using VPC peering to connect any VPC, you must ensure that there is no network address space overlap between the networks that you intend to route traffic between your VPCs and Ansible Automation Platform from GCP Marketplace’s VPC address space. The GCP Portal should prevent peering if this is attempted.
Configure VPC peering with Ansible Automation Platform with the following procedure.
Procedure
- In the GCP Portal, navigate to VPC Network.
- In the VPC menu, select VPC Network Peering.
- Click Create peering connection.
- Click CONTINUE.
- In the Name field, enter the name of the peering connection that you need.
- In the Your VPC Network field, select the first VPC that you plan to peer.
In the Peered VPC Network field, select the second VPC to peer. This must be the Ansible Automation Platform from GCP Marketplace VPC.
- Subnet routes between these two networks are created by default. Therefore, access to Ansible Automation Platform can occur from VMs that reside on the peered VPC. However, if you have more complex routing, such as a hub-and-spoke network model, then other routes must be created.
- Select Exchange custom routes and Exchange subnet routes with public IP carefully. Google provides explanations what each fields does. Your selection affects how traffic flows through your VPCs. Normally, these checkboxes configure routing between the newly peered networks and other networks through the route table exchange and enable network traffic to traverse multiple networks (transit routing).
- Click Create.
For additional information on routing tables, firewalls and other networking components regarding VPC Peering, see the GCP documentation.
5.4. Using an external load balancer
It is possible to expose Ansible automation controller and Ansible private automation hub to the public internet if you want users to have access to the platform from any internet connected machine.
This is not recommended as a best practice for security reasons.
However this implementation can be secured with different GCP tools. This section describes how to connect a load balancer that faces the public internet, but it does not include steps to harden access through Google’s security products. Only use this approach if you intend to protect the public endpoints with Google Cloud Armor or similar product(s).
Ansible Automation Platform from GCP Marketplace is deployed with two internal application load balancers. These load balancers direct traffic within local VPCs and must remain part of the deployment even if you configure public load balancers.
Procedure
- Select the main menu from the top left.
- Select Network Services. If you do not see Network Services, then select View All Products.
- Select Load Balancing.
- In the top menu, select CREATE LOAD BALANCER.
- Select the Application Load Balancer (HTTP/S) tile and click START CONFIGURATION.
- Select From Internet to my VMs or serverless services and Global external Application Load Balancer.
- Click CONTINUE.
-
Give your load balancer a name, for example,
<DeploymentName>-aap-<cntrlr/hub>-ext-lb - Ensure that Frontend configuration is selected at the left of the screen.
On the Frontend configuration page, complete the following fields:
- Protocol: HTTPS.
- Port: 443.
- IP Address: Select an existing IP address or create a new one.
- Certificate: You can use your own SSL Certificate or use a Google managed certificate.
SSL Policy: GCP default, or another configured policy.
NoteFor more information, see SSL Certificates
- Click DONE.
- Select Backend configuration from the menu on the left.
- Click the Backend services & backend buckets drop-down.
Click CREATE A BACKEND SERVICE.
-
Give your backend service a name, for example,
<DeploymentName>-aap-<cntrlr/hub>-ext-lb-bknd-svc - Set Backend type to Instance group.
-
Set Protocol to
HTTPSand Named Port tohttps. -
Change Timeout to
86400. Scroll down to the Backends section and in the New backend field, select the Instance group drop-down. Select the correct instance group.
For the automation controller load balancer, the correct instance group has the suffix
-aap-cntrlr-igm.For the automation hub load balancer, the correct instance group has the suffix
-aap-hub-igm.- In the resulting dialog box, select USE EXISTING PORT NAME.
- Set Balancing mode to Rate.
- Set Maximum RPS to 300.
- Scroll down until you see Cloud CDN. Unselect the checkbox for Cloud CDN.
- Scroll down until you see a text box showing Health check.
- Select the drop-down menu and click CREATE A HEALTH CHECK.
-
Enter a name for your health check, for example,
<DeploymentName>-aap-<cntrlr/hub>-ext-lb-hc For automation controller, use the following health check settings
-
In the Health Check dialog box, set Protocol to
HTTPS, and Port to8052. -
Set Request to
/api/v2/ping/.
-
In the Health Check dialog box, set Protocol to
For automation hub, use the following health check settings
-
In the Health Check dialog box, set Protocol to
HTTPS, and Port to8080. -
Set Request to
/api/galaxy/pulp/api/v3/status/.
-
In the Health Check dialog box, set Protocol to
- Scroll down to Health criteria section.
- In the Check interval field, enter the value 15.
- In the Timeout field, enter the value 10.
- In the Healthy threshold field, enter the value 2.
- In the Unhealthy threshold field, enter the value 10.
Click SAVE.
This returns you to the Backend services & backend buckets window.
Click CREATE.
This returns you to Backend configuration section.
- Click OK.
- Click CREATE to create the load balancer for the automation controller or automation hub UI. This will take a few minutes to complete.
-
Give your backend service a name, for example,
- A load balancer has now been created.
- Configure the DNS record for the domain that you used in your SSL certificate to point to the IP address of the load balancer.
At this point you should have accesss to the Ansible Automation Platform automation controller UI. You can log in after you retrieve the administration password.
Repeat the same process for private automation hub. The process is identical except for selecting the instance group -aap-hub-igm during backend configuration.