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.

Important
  • PROXY_IP_WHITELIST requires proxies in the list are properly sanitizing header input and correctly setting an X-Forwarded-For value equal to the real source IP of the client. {ControllerNameStart} can rely on the IP addresses and hostnames in PROXY_IP_WHITELIST to provide non-spoofed values for the X-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 defines PROXY_IP_WHITELIST that contains only the originating IP addresses of trusted proxies or load balancers.

Procedure

  1. 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

  1. On the automation controller node, open remote_host_headers.py in a text editor:

    $ vi /etc/tower/conf.d/remote_host_headers.py`
  2. 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.

Important
  • 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