Operating Ansible Automation Platform


Red Hat Ansible Automation Platform 2.5

Post installation configurations to ensure a smooth deployment of Ansible Automation Platform installation

Red Hat Customer Content Services

Abstract

This guide provides instructions and guidance on post installation activities for Red Hat Ansible Automation Platform.

Preface

After installing Red Hat Ansible Automation Platform, your system might need extra configuration to ensure your deployment runs smoothly. This guide provides procedures for configuration tasks that you can perform after installing Red Hat Ansible Automation Platform.

Disclaimer: Links contained in this information to external website(s) are provided for convenience only. Red Hat has not reviewed the links and is not responsible for the content or its availability. The inclusion of any link to an external website does not imply endorsement by Red Hat of the website or their entities, products or services. You agree that Red Hat is not responsible or liable for any loss or expenses that may result due to your use of (or reliance on) the external site or content.

Providing feedback on Red Hat documentation

If you have a suggestion to improve this documentation, or find an error, you can contact technical support at https://access.redhat.com to open a request.

If you are an organization administrator, you must create a service account and use the client ID and client secret to activate your subscription.

If you do not have administrative access, you can enter your Red Hat username and password in the Client ID and Client secret fields, to locate and add your subscription to your Ansible Automation Platform instance.

Note

If you enter your client ID and client secret but cannot locate your subscription, you might not have the correct permissions set on your service account. For more information and troubleshooting guidance for service accounts, see Configure Ansible Automation Platform to authenticate through service account credentials.

For Red Hat Satellite, input your Satellite username and Satellite password in the fields below.

Red Hat Ansible Automation Platform uses available subscriptions or a subscription manifest to authorize the use of Ansible Automation Platform. To obtain a subscription, you can do either of the following:

  1. Use your Red Hat username and password, service account credentials, or Satellite credentials when you launch Ansible Automation Platform.
  2. Upload a subscriptions manifest file either using the Red Hat Ansible Automation Platform interface or manually in an Ansible Playbook.

To activate Ansible Automation Platform using credentials, see Activate with credentials.

To activate Ansible Automation Platform with a manifest file, see Activate with a manifest file.

You can configure Red Hat Ansible Automation Platform to communicate with traffic using a proxy. Proxy servers act as an intermediary for requests from clients seeking resources from other servers. A client connects to the proxy server, requesting some service or available resource from a different server, and the proxy server evaluates the request as a way to simplify and control its complexity. The following sections describe the supported proxy configurations and how to set them up.

A forward proxy deals with client traffic, regulating and securing it. To provide proxy server support, automation controller handles proxied requests (such as ALB, NLB , HAProxy, Squid, Nginx and tinyproxy in front of automation controller) using the REMOTE_HOST_HEADERS list variable in the automation controller settings. By default, REMOTE_HOST_HEADERS is set to ["REMOTE_ADDR", "REMOTE_HOST"].

To enable proxy server support, edit the REMOTE_HOST_HEADERS field in the settings page for your automation controller:

Procedure

  1. From the navigation panel, select SettingsAutomation ExecutionSystem.
  2. Click Edit
  3. In the Remote Host Headers field, enter the following values:

    [
      "HTTP_X_FORWARDED_FOR",
      "REMOTE_ADDR",
      "REMOTE_HOST"
    ]
    Copy to Clipboard Toggle word wrap
  4. Click Save to save your settings.

Automation controller determines the remote host’s IP address by searching through the list of headers in Remote Host Headers until the first IP address is located.

2.2. Known proxies

When automation controller 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 automation controller. If automation controller is reachable without use of the proxy/load balancer, or if the proxy does not validate the header, the value of X-Forwarded-For can be falsified to fake the originating IP addresses.

Using HTTP_X_FORWARDED_FOR in the REMOTE_HOST_HEADERS setting poses a vulnerability.

To avoid this, you can configure a list of known proxies that are allowed.

Procedure

  1. From the navigation panel, select SettingsAutomation ExecutionSystem.
  2. Enter a list of proxy IP addresses from which the service should trust custom remote header values in the Proxy IP Allowed List field.

    Note

    Load balancers and hosts that are not on the known proxies list result in a rejected request.

2.2.1. Configuring known proxies

To configure a list of known proxies for your automation controller, add the proxy IP addresses to the Proxy IP Allowed List field in the System Settings page.

Procedure

  1. From the navigation panel, select SettingsAutomation ExecutionSystem.
  2. In the Proxy IP Allowed List field, enter IP addresses that are permitted to connect to your automation controller, using the syntax in the following example:

    Example Proxy IP Allowed List entry

    [
      "example1.proxy.com:8080",
      "example2.proxy.com:8080"
    ]
    Copy to Clipboard Toggle word wrap

    Important
    • Proxy IP Allowed List 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. Automation controller can rely on the IP addresses and hostnames in Proxy IP Allowed List to provide non-spoofed values for X-Forwarded-For.
    • 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_ALLOWED_LIST that contains only the originating IP addresses of trusted proxies or load balancers.
  3. Click Save to save the settings.

A reverse proxy manages external requests to servers, offering load balancing and concealing server identities for added security. You can support a reverse proxy server configuration by adding HTTP_X_FORWARDED_FOR to the Remote Host Headers field in the Systems Settings. 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. From the navigation panel, select SettingsAutomation ExecutionSystem.
  2. In the Remote Host Headers field, enter the following values:

    [
      "HTTP_X_FORWARDED_FOR",
      "REMOTE_ADDR",
      "REMOTE_HOST"
    ]
    Copy to Clipboard Toggle word wrap
  3. Add the lines below to /etc/tower/conf.d/custom.py to ensure the application uses the correct headers:

    USE_X_FORWARDED_PORT = True
    USE_X_FORWARDED_HOST = True
    Copy to Clipboard Toggle word wrap
  4. Click Save to save the settings.

2.4. Enable sticky sessions

By default, an application load balancer routes each request independently to a registered target based on the chosen load-balancing algorithm. To avoid authentication errors when running multiple instances of automation hub behind a load balancer, you must enable sticky sessions. Enabling sticky sessions sets a custom application cookie that matches the cookie configured on the load balancer to enable stickiness. This custom cookie can include any of the cookie attributes required by the application.

You can deploy Ansible Automation Platform so that egress from the platform for various purposes functions properly through proxy servers. Egress proxy allows clients to make indirect (through a proxy server) requests to network services. The client first connects to the proxy server and requests some resource, for example, email, located on another server. The proxy server then connects to the specified server and retrieves the resource from it.

3.1. Overview

The egress proxy should be configured on the system and component level of Ansible Automation Platform, for all the RPM and containerized installation methods. For containerized installers, the system proxy configuration for podman on the nodes solves most of the problems with access through the proxy. For RPM installation, both system and component configurations are needed.

3.1.1. Proxy backends

For HTTP and HTTPS proxies you can use a squid server. Squid is a forward proxy for the Web supporting HTTP, HTTPS, and FTP, reducing bandwidth and improving response times by caching and reusing frequently-requested web pages. It is licensed under the GNU GPL. Forward proxies are systems that intercept network traffic going to another network (typically the internet) and send it on the behalf of the internal systems. The squid proxy enables all required communication to pass through it.

Make sure all the required Ansible Automation Platform control plane ports are opened on the squid proxy backend. Ansible Automation Platform-specific ports:

acl Safe_ports port 81
acl Safe_ports port 82
acl Safe_ports port 389
acl Safe_ports port 444
acl Safe_ports port 445
acl SSL_ports port 22
Copy to Clipboard Toggle word wrap

The following ports are for containerized installations:

acl SSL_ports port 444
acl SSL_ports port 445
acl SSL_ports port 8443
acl SSL_ports port 8444
acl SSL_ports port 8445
acl SSL_ports port 8446
acl SSL_ports port 44321
acl SSL_ports port 44322

http_access deny !Safe_ports
http_access deny CONNECT !SSL_ports
Copy to Clipboard Toggle word wrap

3.2. System proxy configuration

The outbound proxy is configured on the system level for all the nodes in the control plane.

The following environment variables must be set:

http_proxy=“http://external-proxy_0:3128”
https_proxy=“http://external-proxy_0:3128”
no_proxy=“localhost,127.0.0.0/8,10.0.0.0/8”
Copy to Clipboard Toggle word wrap

You can also add those variables to the /etc/environment file to make them permanent.

The installation program ensures that all external communication during the installation goes through the proxy. For containerized installation, those variables ensure that the podman uses the egress proxy.

3.3. Automation controller settings

After using the RPM installation program, you must configure automation controller to use egress proxy.

Note

This is not required for containerized installers because podman uses system configured proxy and redirects all the container traffic to the proxy.

For automation controller, set the AWX_TASK_ENV variable in /api/v2/settings/. To do this through the UI use the following procedure:

Procedure

  1. From the navigation panel, select SettingsAutomation ExecutionJob.
  2. Click Edit.
  3. Add the variables to the Extra Environment Variables field

    and set:

    "AWX_TASK_ENV": {
    "http_proxy": "http://external-proxy_0:3128",
    "https_proxy": "http://external-proxy_0:3128",
    "no_proxy": "localhost,127.0.0.0/8"
                    }
    Copy to Clipboard Toggle word wrap

The following procedure for RPM-based Ansible Automation Platform describes how to use automation controller Project Sync by using the SSH protocol to work with a proxy server.

Procedure

  1. Perform the following steps on the automation controller nodes. If ansible-builder has not been installed yet, install it first.

    # subscription-manager repos --enable ansible-automation-platform-2.5-for-rhel-8-x86_64-rpms
    # dnf install ansible-builder
    Copy to Clipboard Toggle word wrap
  2. Build a custom execution environment.

    1. First, create a work directory:

      # su - awx
      $ mkdir -p builder/newee
      $ cd builder/newee
      Copy to Clipboard Toggle word wrap
  3. Create an execution-environment.yml file with the following content:

    version: 1
    
    build_arg_defaults:
      EE_BASE_IMAGE: 'registry.redhat.io/ansible-automation-platform-24/ee-supported-rhel8:latest'
    
    additional_build_steps:
      prepend:
        - RUN microdnf install -y nc
    Copy to Clipboard Toggle word wrap
  4. Log in to registry.redhat.io.

    $ podman login registry.redhat.io
    Copy to Clipboard Toggle word wrap
  5. Run ansible-builder to start the building process.

    $ cd /var/lib/awx/builder/newee/
    $ ansible-builder build -t my-env -v 3
    Copy to Clipboard Toggle word wrap
  6. Add the custom execution environment you created.
  7. On the navigation panel, select Automation ExecutionInfrastructureExecution Environments.
  8. Click Create execution environment.
  9. In the Image field add localhost/my-env:latest.
  10. Click Create execution environment.
  11. Re-run the Ansible Automation Platform installation program with the following steps to replace the execution environment from the default to the customized environment which will be used as a Project syncs.

    Note

    Backup Ansible Automation Platform before running the installation program.

    # ./setup.sh -b
    Copy to Clipboard Toggle word wrap
  12. Create an automationcontroller file under the group_vars directory in the same location as the setup.sh file. The file contents are as follows:

    control_plane_execution_environment: localhost/my-env
    Copy to Clipboard Toggle word wrap
  13. Run setup.sh

    # ./setup.sh
    Copy to Clipboard Toggle word wrap
  14. Create ssh_config under the directory. For example:

    Host github.com
    Hostname ssh.github.com
    ProxyCommand nc --proxy-type http --proxy proxy.example.com:port %h %p
    User git
    Copy to Clipboard Toggle word wrap
  15. Add the ssh_config file’s directory path in PATH to expose the isolated jobs so that the container execution environment can read ssh_config file.
  16. In the navigation panel, select SettingsAutomation ExecutionJob.
  17. Click Edit.
  18. If the ssh_config file has been created as /var/lib/awx/.ssh/ssh_config, add this to Paths to expose to isolated jobs

    Note

    Ensure ssh_config is owned by the AWX user. (#chown awx:awx /var/lib/awx/.ssh/ssh_config)

    [
    "/var/lib/awx/.ssh:/etc/ssh:O"
    ]
    Copy to Clipboard Toggle word wrap

To enable a configurable proxy environment for AWS inventory synchronization, you can manually edit the override configuration file or set the configuration in the platform UI:

  1. Manually edit /usr/lib/systemd/system/receptor.service.d/override.conf and add the following http_proxy environment variables there:

    http_proxy:<value>
    https_proxy:<value>
    proxy_username:<value>
    Proxy_password:<value>
    Copy to Clipboard Toggle word wrap

    Or

  2. To do this through the UI use the following procedure:

Procedure

  1. From the navigation panel, select SettingsAutomation ExecutionJob.
  2. Click Edit.
  3. Add the variables to the Extra Environment Variables field

    For example: *

"AWX_TASK_ENV": {
        "no_proxy": "localhost,127.0.0.0/8,10.0.0.0/8",
        "http_proxy": "http://proxy_host:3128/",
        "https_proxy": "http://proxy_host:3128/"
                },
Copy to Clipboard Toggle word wrap

3.5. Configuring Proxy settings on automation hub

If your private automation hub is behind a network proxy, you can configure proxy settings on the remote to sync content located outside of your local network.

Prerequisites

  • You have Modify Ansible repo content permissions. For more information on permissions, see Access management and authentication.
  • You have a requirements.yml file that identifies those collections to synchronize from Ansible Galaxy as in the following example:

    Requirements.yml example

    collections:
      # Install a collection from Ansible Galaxy.
      - name: community.aws
        version: 5.2.0
        source: https://galaxy.ansible.com
    Copy to Clipboard Toggle word wrap

Procedure

  1. Log in to Ansible Automation Platform.
  2. From the navigation panel, select Automation ContentRemotes.
  3. In the Details tab in the Community remote, click Edit remote.
  4. In the YAML requirements field, paste the contents of your requirements.yml file.
  5. Click Save remote.

Result

You can now synchronize collections identified in your requirements.yml file from Ansible Galaxy to your private automation hub.

For Event-Driven Ansible, there are no global settings to set a proxy. You must specify the proxy for every project.

Procedure

  1. From the navigation panel, select Automation DecisionsProjects.
  2. Click Create Project

Use the Proxy field.

You can route outbound communication from the receptor on an automation mesh node through a proxy server. If your proxy does not strip out TLS certificates then an installation of Ansible Automation Platform automatically supports the use of a proxy server.

Every node on the mesh must have a Certifying Authority that the installer creates on your behalf.

The default install location for the Certifying Authority is:

/etc/receptor/tls/ca/mesh-CA.crt

The certificates and keys created on your behalf use the nodeID for their names:

For the certificate: /etc/receptor/tls/NODEID.crt

For the key: /etc/receptor/tls/NODEID.key

Chapter 4. Advanced configurations

As a platform administrator, you can implement advanced configurations to customize Ansible Automation Platform, including database connections, logging, caching, and gRPC server parameters.

4.1. settings.py file

As a platform administrator, you can modify the settings.py file to configure various aspects of Ansible Automation Platform, such as database connections, logging configurations, caching, and more.

There are two settings.py files; the default settings.py that is part of the codebase and must not be edited, and an override file that can be used to override the default values.

The location and management of the override settings.py file can differ based on your deployment (RPM-based, container-based installation, or operator-based installation).

4.1.1. RPM deployments

The override settings.py file in an RPM-based setup can be edited directly, and changes take effect after restarting the platform gateway service. If you choose to edit the file, be sure to use the proper syntax and values. The override settings.py file is located in the following directory:

/etc/ansible-automation-platform/gateway/settings.py
Copy to Clipboard Toggle word wrap

4.1.2. Container-based deployments

For container-based installation deployments, Ansible Automation Platform runs within containers and the settings.py file is included inside the container. However, directly editing the settings.py file in container-based installation deployments is not recommended because the settings.py file is overwritten during upgrades or new installs.

To customize settings in container-based installation deployments, you can use the extra_settings parameter to ensure that customizations persist through installer updates. For more information, see Inventory file variables in the Containerized installation guide.

4.1.3. Operator-based deployments

For operator-based installation deployments, the settings.py file is typically located inside the container, however, users cannot modify the settings.py files directly in the container because containers in Red Hat OpenShift Container Platform are read-only.

Instead, for operator-based deployments, you can modify the settings for the platform gateway using the spec.extra_settings parameter on the Ansible Automation Platform custom resource.

4.2. grpc_settings.py file

Platform administrators can use the grpc_settings.py file to define special or custom parameters for the gRPC server.

There are two gRPC settings files: the default grpc_default.py that is part of the codebase and must not be edited, and an override file that can be used to override the default values. The grpc_default.py file includes database keepalive OPTIONS to help maintain a healthy gRPC connection and prevent interruptions. If it was necessary to change these defaults, the grpc_settings.py file can be used to override values from the grpc_defauly.py file.

The location and management of the override grpc_settings.py file can differ based on your deployment (RPM-based, container-based installation or operator-based installation).

4.2.1. RPM deployments

The override grpc_settings.py file in an RPM-based setup can be edited directly, and changes take effect after restarting the gateway systemd service. If you choose to edit the file, be sure to use the proper syntax and values. The override grpc_settings.py file is located in the following directory:

/etc/ansible-automation-platform/gateway/grpc_settings.py
Copy to Clipboard Toggle word wrap

The gRPC server is responsible for helping with authentication between the different platform services. Altering the settings in the grpc_settings.py file can significantly impact the behavior and performance of the gRPC connection, especially in terms of connection stability.

It is important to thoroughly test any changes made to the gRPC settings before deploying them to production to ensure that the gRPC server functions as expected.

4.3. Loading order of settings

The platform gateway utilizes the Dynaconf library for managing its application settings. Dynaconf follows a layered configuration approach, where settings are loaded from multiple sources in a defined order, with later sources overriding earlier ones. Ansible Automation Platform loads settings in the following sequence:

  1. Application settings.py: This file is in the application itself and defines the loading order and location of additional settings files.
  2. Application default settings: The platform loads default settings from a defaults.py file, which is part of the application itself. This file includes general configurations for both the API Server and the gRPC server.
  3. Customer override file: The /etc/ansible-automation-platform/gateway/settings.py file is automatically installed and can be used to override any configuration in defaults.py. Changes to this file affect both the API and gRPC servers.
  4. Application gRPC default settings: After the customer override file, the application loads additional default settings for the gRPC server only from the grpc_default.py file. Specifically, this file includes database OPTIONS for the gRPC server, such as the keepalive parameters.
  5. Customer gRPC override file: The file /etc/ansible-automation-platform/gateway/grpc_settings.py, if present, is loaded next and any settings contained in this file are applied only to the gRPC server.
  6. Platform override settings file: Any settings in the /etc/ansible-automation-platform/settings.py file are applied to both the gRPC server and the API server. If there are multiple Ansible Automation Platform services on a single node, items in this file are applied to all services.
  7. ENV vars: Environment variables, where you can configure certain Ansible Automation Platform settings outside of the configuration files, are loaded last. They override any previously loaded settings.

You can change how you participate in usability analytics and data collection from automation controller by opting out or changing your settings in the automation controller user interface.

5.1. Usability analytics and data collection

Usability data collection is included with automation controller to collect data to better understand how automation controller users specifically interact with automation controller, to help enhance future releases, and to continue streamlining your user experience.

Only users installing a trial of automation controller or a fresh installation of automation controller are opted-in for this data collection.

You can control how automation controller collects data from the SettingsAutomation ExecutionSystem menu.

Procedure

  1. Log in to your automation controller.
  2. From the navigation panel, select SettingsAutomation ExecutionSystem.
  3. Select Gather data for Automation Analytics to enable automation controller to gather data on automation and send it to Automation Analytics.

If your current SSL/TLS certificates have expired or will expire soon, you can either renew or replace the SSL/TLS certificates used by Ansible Automation Platform.

You must renew the SSL/TLS certificates if you need to regenerate them with new information such as new hosts.

You must replace the SSL/TLS certificates if you want to use certificates signed by an internal certificate authority.

6.1. Container-based installations

You can change the TLS certificates and keys for your container-based Ansible Automation Platform installation. This process involves a preparation step, either providing new custom certificates or deleting or moving the old certificates, followed by running the installation program.

The following procedure describes how to update the TLS certificates and keys by using the installation program.

Procedure

  1. To prepare the certificates and keys, choose one of the following methods:

    • To provide custom certificates - For each service that requires updated TLS certificates, copy the new certificates and keys to a path relative to the Ansible Automation Platform installer. Then update the inventory file variables with the absolute paths to the new files.

      # Platform gateway
      gateway_tls_cert=<path_to_tls_certificate>
      gateway_tls_key=<path_to_tls_key>
      gateway_pg_tls_cert=<path_to_tls_certificate>
      gateway_pg_tls_key=<path_to_tls_key>
      gateway_redis_tls_cert=<path_to_tls_certificate>
      gateway_redis_tls_key=<path_to_tls_key>
      
      # Automation controller
      controller_tls_cert=<path_to_tls_certificate>
      controller_tls_key=<path_to_tls_key>
      controller_pg_tls_cert=<path_to_tls_certificate>
      controller_pg_tls_key=<path_to_tls_key>
      
      # Automation hub
      hub_tls_cert=<path_to_tls_certificate>
      hub_tls_key=<path_to_tls_key>
      hub_pg_tls_cert=<path_to_tls_certificate>
      hub_pg_tls_key=<path_to_tls_key>
      
      # Event-Driven Ansible
      eda_tls_cert=<path_to_tls_certificate>
      eda_tls_key=<path_to_tls_key>
      eda_pg_tls_cert=<path_to_tls_certificate>
      eda_pg_tls_key=<path_to_tls_key>
      eda_redis_tls_cert=<path_to_tls_certificate>
      eda_redis_tls_key=<path_to_tls_key>
      
      # PostgreSQL
      postgresql_tls_cert=<path_to_tls_certificate>
      postgresql_tls_key=<path_to_tls_key>
      
      # Receptor
      receptor_tls_cert=<path_to_tls_certificate>
      receptor_tls_key=<path_to_tls_key>
      Copy to Clipboard Toggle word wrap
    • To generate new certificates - If you want the installation program to generate a new certificate for a service, delete or move the existing certificates and keys.

      Expand
      Table 6.1. Certificate and key file paths per service
      ServiceCertificate file pathKey file path

      Automation controller

      ~/aap/controller/etc/tower.cert

      ~/aap/controller/etc/tower.key

      Event-Driven Ansible

      ~/aap/eda/etc/eda.cert

      ~/aap/eda/etc/eda.key

      Platform gateway

      ~/aap/gateway/etc/gateway.cert

      ~/aap/gateway/etc/gateway.key

      Automation hub

      ~/aap/hub/etc/pulp.cert

      ~/aap/hub/etc/pulp.key

      PostgreSQL

      ~/aap/postgresql/server.crt

      ~/aap/postgresql/server.key

      Receptor

      ~/aap/receptor/etc/receptor.crt

      ~/aap/receptor/etc/receptor.key

      Redis

      ~/aap/redis/server.crt

      ~/aap/redis/server.key

  2. After preparing your certificates, run the install playbook from your installation directory:

    ansible-playbook -i <inventory_file_name> ansible.containerized_installer.install
    Copy to Clipboard Toggle word wrap

Verification

Verify that the new TLS certificates are in use by checking that the services are running and accessible. To do this, check a specific endpoint by using curl:

$ curl -vk https://<hostname_or_ip>:<port_number>/api/v2/
Copy to Clipboard Toggle word wrap

The output of this command gives details about the TLS handshake. Look for the following output to confirm the correct certificate is being used:

*  SSL certificate verify OK
Copy to Clipboard Toggle word wrap

6.2. Operator-based installations

The following procedure describes how to change the SSL certificate and key for automation controller running on OpenShift Container Platform.

Procedure

  1. Copy the signed SSL certificate and key to a secure location.
  2. Create a TLS secret within OpenShift:

    oc create secret tls ${CONTROLLER_INSTANCE}-certs-$(date +%F) --cert=/path/to/ssl.crt --key=/path/to/ssl.key
    Copy to Clipboard Toggle word wrap
  3. Modify the automation controller custom resource to add route_tls_secret and the name of the new secret to the spec section.

    oc edit automationcontroller/${CONTROLLER_INSTANCE}
    Copy to Clipboard Toggle word wrap
    ...
    spec:
      route_tls_secret: automation-controller-certs-2023-04-06
    ...
    Copy to Clipboard Toggle word wrap

The name of the TLS secret is arbitrary. In this example, it is timestamped with the date that the secret is created, to differentiate it from other TLS secrets applied to the automation controller instance.

  1. Wait a few minutes for the changes to be applied.
  2. Verify that new SSL certificate and key have been installed:

    true | openssl s_client -showcerts -connect ${CONTROLLER_FQDN}:443
    Copy to Clipboard Toggle word wrap

The following procedure describes how to change the SSL certificate and key for automation hub running on OpenShift Container Platform.

Procedure

  1. Copy the signed SSL certificate and key to a secure location.
  2. Create a TLS secret within OpenShift:

    oc create secret tls ${AUTOMATION_HUB_INSTANCE}-certs-$(date +%F) --cert=/path/to/ssl.crt --key=/path/to/ssl.key
    Copy to Clipboard Toggle word wrap
  3. Modify the automation hub custom resource to add route_tls_secret and the name of the new secret to the spec section.

    oc edit automationhub/${AUTOMATION_HUB_INSTANCE}
    Copy to Clipboard Toggle word wrap
    ...
    spec:
      route_tls_secret: automation-hub-certs-2023-04-06
    ...
    Copy to Clipboard Toggle word wrap

The name of the TLS secret is arbitrary. In this example, it is timestamped with the date that the secret is created, to differentiate it from other TLS secrets applied to the automation hub instance.

  1. Wait a few minutes for the changes to be applied.
  2. Verify that new SSL certificate and key have been installed:

    true | openssl s_client -showcerts -connect ${CONTROLLER_FQDN}:443
    Copy to Clipboard Toggle word wrap

6.3. RPM-based installations

To renew or change SSL certificates for RPM-based installations, you can edit the inventory file and run the installation program. The installation program verifies that all Ansible Automation Platform components are working.

Alternatively, you can change the SSL certificates manually. This is quicker, but there is no automatic verification.

Red Hat recommends that you use the installation program to make changes to your Ansible Automation Platform deployment.

The following steps regenerate new SSL/TLS certificates for all Ansible Automation Platform components.

Procedure

  1. Add aap_service_regen_cert=true to the inventory file in the [all:vars] section:

    [all:vars]
    aap_service_regen_cert=true
    Copy to Clipboard Toggle word wrap
  2. Run the installer.

Verification

  • Validate the CA file and certificate file on Event-Driven Ansible controller:

    openssl verify -CAfile ansible-automation-platform-managed-ca-cert.crt /etc/ansible-automation-platform/eda/server.cert
    openssl s_client -connect <EDA_FQDN>:443
    Copy to Clipboard Toggle word wrap
  • Validate the CA file and certificate file on platform gateway:

    openssl verify -CAfile ansible-automation-platform-managed-ca-cert.crt /etc/ansible-automation-platform/gateway/gateway.cert
    openssl s_client -connect <GATEWAY_FQDN>:443
    Copy to Clipboard Toggle word wrap
  • Validate the CA file and certificate file on automation hub:

    openssl verify -CAfile ansible-automation-platform-managed-ca-cert.crt /etc/pulp/certs/pulp_webserver.crt
    openssl s_client -connect <HUB_FQDN>:443
    Copy to Clipboard Toggle word wrap
  • Validate the CA file and certificate file on automation controller:

    openssl verify -CAfile ansible-automation-platform-managed-ca-cert.crt /etc/tower/tower.cert
    openssl s_client -connect <CONTROLLER_FQDN>:443
    Copy to Clipboard Toggle word wrap

The following procedure describes how to change the SSL/TLS certificate and key in the inventory file.

Prerequisites

  • The certificates must be in PEM format.
  • If there is an intermediate certificate authority, you must append it to the server certificate.
  • Use the correct order for the certificates: The server certificate comes first, followed by the intermediate certificate authority.

For further information, see the ssl certificate section of the NGINX documentation.

Procedure

  1. Copy the new SSL/TLS certificates and keys to a path relative to the Ansible Automation Platform installer.
  2. Add the absolute paths of the SSL/TLS certificates and keys to the inventory file. Refer to Inventory file variables for guidance on setting these variables.

    • Event-Driven Ansible controller: automationedacontroller_ssl_cert, automationedacontroller_ssl_key, custom_ca_cert
    • Platform gateway: automationgateway_ssl_cert, automationgateway_ssl_key, custom_ca_cert
    • Automation hub: automationhub_ssl_cert, automationhub_ssl_key, custom_ca_cert
    • Automation controller: web_server_ssl_cert, web_server_ssl_key, custom_ca_cert

      Note

      The custom_ca_cert must be the root certificate authority that signed the intermediate certificate authority. This file is installed in /etc/pki/ca-trust/source/anchors.

  3. Run the installation program.

The following procedure describes how to change SSL/TLS certificates and keys manually for all Ansible Automation Platform components.

Procedure

  1. Backup the current SSL/TLS certificate:

    cp <CERT_PATH> <CERT_PATH>-$(date +%F)
    Copy to Clipboard Toggle word wrap
  2. Backup the current key files:

    cp <KEY_PATH> <KEY_PATH>-$(date +%F)
    Copy to Clipboard Toggle word wrap
  3. Copy the new SSL/TLS certificate to the certificate path.
  4. Copy the new key to the key path.
  5. Restore the SELinux context:

    restorecon -v <CERT_PATH> <KEY_PATH>
    Copy to Clipboard Toggle word wrap
  6. Set appropriate permissions for the certificate and key files:

    chown <OWNER>:<GROUP> <CERT_PATH> <KEY_PATH>
    chmod 0600 <CERT_PATH> <KEY_PATH>
    Copy to Clipboard Toggle word wrap
  7. Test the NGINX configuration:

    nginx -t
    Copy to Clipboard Toggle word wrap
  8. Reload NGINX:

    systemctl reload nginx.service
    Copy to Clipboard Toggle word wrap
  9. Verify that new SSL/TLS certificate and key have been installed:

    true | openssl s_client -showcerts -connect <COMPONENT_FQDN>:443
    Copy to Clipboard Toggle word wrap
    Expand
    Table 6.2. SSL/TLS certificate and key file paths per service
    ServiceCertificate file pathKey file pathOwner:Group

    Automation controller

    /etc/tower/tower.cert

    /etc/tower/tower.key

    root:awx

    Automation hub

    /etc/pulp/certs/pulp_webserver.crt

    /etc/pulp/certs/pulp_webserver.key

    root:pulp

    Event-Driven Ansible controller

    /etc/ansible-automation-platform/eda/server.cert

    /etc/ansible-automation-platform/eda/server.key

    root:eda

    Platform gateway

    /etc/ansible-automation-platform/gateway/gateway.cert

    /etc/ansible-automation-platform/gateway/gateway.key

    root:gateway

Legal Notice

Copyright © 2025 Red Hat, Inc.
The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at http://creativecommons.org/licenses/by-sa/3.0/. In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version.
Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.
Red Hat, Red Hat Enterprise Linux, the Shadowman logo, the Red Hat logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
Java® is a registered trademark of Oracle and/or its affiliates.
XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
Node.js® is an official trademark of Joyent. Red Hat is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.
The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation's permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.
All other trademarks are the property of their respective owners.
Red Hat logoGithubredditYoutubeTwitter

Learn

Try, buy, & sell

Communities

About Red Hat Documentation

We help Red Hat users innovate and achieve their goals with our products and services with content they can trust. Explore our recent updates.

Making open source more inclusive

Red Hat is committed to replacing problematic language in our code, documentation, and web properties. For more details, see the Red Hat Blog.

About Red Hat

We deliver hardened solutions that make it easier for enterprises to work across platforms and environments, from the core datacenter to the network edge.

Theme

© 2026 Red Hat
Back to top