Chapter 5. Configuring proxy support for Red Hat Ansible Automation Platform
You can configure Red Hat Ansible Automation Platform to communicate with traffic using a proxy. This section describes the supported proxy configurations and how to set them up.
5.1. Configuring known proxies
You can configure a list of known proxies that are allowed to reach your automation controller. Load balancers and hosts that are not on the list will result in a rejected request.
5.1.1. Known proxies
When Tower is configured with REMOTE_HOST_HEADERS = ['HTTP_X_FORWARDED_FOR', 'REMOTE_ADDR', 'REMOTE_HOST']
, it assumes that the value of X-Forwarded-For
has originated from the proxy/load balancer sitting in front of Tower. In a scenario where Tower is still reachable without use of the proxy/load balancer or when the proxy does not validate the header, X-Forwarded-For
can be spoofed fairly easily to fake the originating IP addresses. Using HTTP_X_FORWARDED_FOR
in the REMOTE_HOST_HEADERS
setting poses a vulnerability that essentially gives users access to certain resources that they should not have.
Example vulnerabilities:
- The host config key for a job template
- The hostname or ansible_(ssh_)host of a host in the job template’s linked inventory
- The url of the job template’s provisioning callback
5.1.1.1. Configuring known proxies
You can configure a list of "known proxies" that are allowed using the PROXY_IP_WHITELIST
setting via the settings API. Load balancers and hosts that are not on the list will result in a rejected request.
-
PROXY_IP_WHITELIST
requires proxies in the list are properly sanitizing header input and correctly setting anX-Forwarded-For
value equal to the real source IP of the client. {ControllerNameStart} can rely on the IP addresses and hostnames inPROXY_IP_WHITELIST
to provide non-spoofed values for theX-Forwarded-For
field. Do not configure
HTTP_X_FORWARDED_FOR
as an item in `REMOTE_HOST_HEADERS`unless all of the following conditions are satisfied:- You are using a proxied environment with ssl termination;
-
The proxy provides sanitization or validation of the
X-Forwarded-For
header to prevent client spoofing; -
/etc/tower/conf.d/remote_host_headers.py
definesPROXY_IP_WHITELIST
that contains only the originating IP addresses of trusted proxies or load balancers.
Procedure
-
On the automation controller node, open
/etc/tower/conf.d/remote_host_headers.py
using a text editor.
Additional resources
- A bulleted list of links to other material closely related to the contents of the procedure module.
- Currently, modules cannot include xrefs, so you cannot include links to other content in your collection. If you need to link to another assembly, add the xref to the assembly that includes this module.
- For more details on writing procedure modules, see the Modular Documentation Reference Guide.
- Use a consistent system for file names, IDs, and titles. For tips, see Anchor Names and File Names in Modular Documentation Reference Guide.
5.2. Configuring a reverse proxy
You can support a reverse proxy server configuring using a header field for HTTP_X_FORWARDED_FOR
. The X-Forwarded-For
(XFF) HTTP header field identifies the originating IP address of a client connecting to a web server through an HTTP proxy or load balancer.
Procedure
On the automation controller node, open
remote_host_headers.py
in a text editor:$ vi /etc/tower/conf.d/remote_host_headers.py`
Setup
REMOTE_HOST_HEADERS
as follows:`REMOTE_HOST_HEADERS = ['HTTP_X_FORWARDED_FOR', 'REMOTE_ADDR', 'REMOTE_HOST']`
5.3. Configuring automation controller websocket connections
You can configure automation controller in order to align the websocket configuration with your nginx or load balancer configuration.
5.3.1. Websocket configuration for automation controller
{ControllerNameStart} nodes connect to all other automation controller nodes via websockets. This interconnect is used to distribute all websocket emitted messages to all other automation controller nodes. This is required because any browser client websocket can subscribe to any job that may be running on any automation controller node. Websocket clients are not routed to specific automation controller nodes. Any automation controller node can handle any websocket request and each automation controller node must know about all websocket messages destined for all clients.
{ControllerNameStart} will automatically handle discovery of other automation controller nodes via the Instance record in the database.
- It is intended that your nodes are broadcasting websocket traffic across a private, trusted subnet (and not the open Internet). Therefore, if you turn off HTTPS for websocket broadcasting, the websocket traffic, comprised mostly of Ansible playbook stdout, is sent between automation controller nodes unencrypted.
5.3.1.1. Configuring automatic discovery of other automation controller nodes
You can configure websocket connections to enable automation controller to automatically handle discovery of other automation controller nodes through the Instance record in the database.
Edit automation controller websocket information for port, protocol, and whether or not to verify certificates when establishing the websocket connections.
BROADCAST_WEBSOCKET_PROTOCOL = 'http' BROADCAST_WEBSOCKET_PORT = 80 BROADCAST_WEBSOCKET_VERIFY_CERT = False