Operating Ansible Automation Platform
Post installation configurations to ensure a smooth deployment of Ansible Automation Platform installation
Abstract
Preface Copy linkLink copied to clipboard!
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 Copy linkLink copied to clipboard!
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.
Chapter 1. Activating Red Hat Ansible Automation Platform Copy linkLink copied to clipboard!
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.
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:
- Use your Red Hat username and password, service account credentials, or Satellite credentials when you launch Ansible Automation Platform.
- 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.
Chapter 2. Configuring proxy support for Red Hat Ansible Automation Platform Copy linkLink copied to clipboard!
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.
2.1. Enabling proxy support through a load balancer Copy linkLink copied to clipboard!
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
- From the navigation panel, select → → .
- Click
In the Remote Host Headers field, enter the following values:
[ "HTTP_X_FORWARDED_FOR", "REMOTE_ADDR", "REMOTE_HOST" ]
[ "HTTP_X_FORWARDED_FOR", "REMOTE_ADDR", "REMOTE_HOST" ]Copy to Clipboard Copied! Toggle word wrap Toggle overflow - Click 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 Copy linkLink copied to clipboard!
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
- From the navigation panel, select → → .
Enter a list of proxy IP addresses from which the service should trust custom remote header values in the Proxy IP Allowed List field.
NoteLoad balancers and hosts that are not on the known proxies list result in a rejected request.
2.2.1. Configuring known proxies Copy linkLink copied to clipboard!
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
- From the navigation panel, select → → .
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" ]
[ "example1.proxy.com:8080", "example2.proxy.com:8080" ]Copy to Clipboard Copied! Toggle word wrap Toggle overflow Important-
Proxy IP Allowed List requires proxies in the list are properly sanitizing header input and correctly setting an
X-Forwarded-Forvalue 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 forX-Forwarded-For. Do not configure
HTTP_X_FORWARDED_FORas 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-Forheader to prevent client spoofing; -
/etc/tower/conf.d/remote_host_headers.pydefinesPROXY_IP_ALLOWED_LISTthat contains only the originating IP addresses of trusted proxies or load balancers.
-
Proxy IP Allowed List requires proxies in the list are properly sanitizing header input and correctly setting an
- Click to save the settings.
2.3. Configuring a reverse proxy through a load balancer Copy linkLink copied to clipboard!
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
- From the navigation panel, select → → .
In the Remote Host Headers field, enter the following values:
[ "HTTP_X_FORWARDED_FOR", "REMOTE_ADDR", "REMOTE_HOST" ]
[ "HTTP_X_FORWARDED_FOR", "REMOTE_ADDR", "REMOTE_HOST" ]Copy to Clipboard Copied! Toggle word wrap Toggle overflow Add the lines below to
/etc/tower/conf.d/custom.pyto ensure the application uses the correct headers:USE_X_FORWARDED_PORT = True USE_X_FORWARDED_HOST = True
USE_X_FORWARDED_PORT = True USE_X_FORWARDED_HOST = TrueCopy to Clipboard Copied! Toggle word wrap Toggle overflow - Click to save the settings.
2.4. Enable sticky sessions Copy linkLink copied to clipboard!
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.
Chapter 3. Configuring Ansible Automation Platform to use egress proxy Copy linkLink copied to clipboard!
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 Copy linkLink copied to clipboard!
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 Copy linkLink copied to clipboard!
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:
The following ports are for containerized installations:
3.2. System proxy configuration Copy linkLink copied to clipboard!
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”
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”
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 Copy linkLink copied to clipboard!
After using the RPM installation program, you must configure automation controller to use egress proxy.
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
- From the navigation panel, select → → .
- Click .
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" }"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 Copied! Toggle word wrap Toggle overflow
3.3.1. Configuring SCM project sync using SSH to work with a proxy in automation controller Copy linkLink copied to clipboard!
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
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
# subscription-manager repos --enable ansible-automation-platform-2.5-for-rhel-8-x86_64-rpms # dnf install ansible-builderCopy to Clipboard Copied! Toggle word wrap Toggle overflow Build a custom execution environment.
First, create a work directory:
su - awx mkdir -p builder/newee cd builder/newee
# su - awx $ mkdir -p builder/newee $ cd builder/neweeCopy to Clipboard Copied! Toggle word wrap Toggle overflow
Create an
execution-environment.ymlfile with the following content:Copy to Clipboard Copied! Toggle word wrap Toggle overflow Log in to registry.redhat.io.
podman login registry.redhat.io
$ podman login registry.redhat.ioCopy to Clipboard Copied! Toggle word wrap Toggle overflow Run ansible-builder to start the building process.
cd /var/lib/awx/builder/newee/ ansible-builder build -t my-env -v 3
$ cd /var/lib/awx/builder/newee/ $ ansible-builder build -t my-env -v 3Copy to Clipboard Copied! Toggle word wrap Toggle overflow - Add the custom execution environment you created.
- On the navigation panel, select → → .
- Click .
-
In the Image field add
localhost/my-env:latest. - Click .
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.
NoteBackup Ansible Automation Platform before running the installation program.
./setup.sh -b
# ./setup.sh -bCopy to Clipboard Copied! Toggle word wrap Toggle overflow Create an
automationcontrollerfile under thegroup_varsdirectory in the same location as thesetup.shfile. The file contents are as follows:control_plane_execution_environment: localhost/my-env
control_plane_execution_environment: localhost/my-envCopy to Clipboard Copied! Toggle word wrap Toggle overflow Run
setup.sh./setup.sh
# ./setup.shCopy to Clipboard Copied! Toggle word wrap Toggle overflow Create
ssh_configunder 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
Host github.com Hostname ssh.github.com ProxyCommand nc --proxy-type http --proxy proxy.example.com:port %h %p User gitCopy to Clipboard Copied! Toggle word wrap Toggle overflow -
Add the
ssh_configfile’s directory path in PATH to expose the isolated jobs so that the container execution environment can readssh_configfile. - In the navigation panel, select → → .
- Click .
If the
ssh_configfile has been created as/var/lib/awx/.ssh/ssh_config, add this to Paths to expose to isolated jobsNoteEnsure
ssh_configis owned by the AWX user. (#chown awx:awx /var/lib/awx/.ssh/ssh_config)[ "/var/lib/awx/.ssh:/etc/ssh:O" ]
[ "/var/lib/awx/.ssh:/etc/ssh:O" ]Copy to Clipboard Copied! Toggle word wrap Toggle overflow
3.4. Enabling a configurable proxy environment for AWS inventory synchronization Copy linkLink copied to clipboard!
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:
Manually edit
/usr/lib/systemd/system/receptor.service.d/override.confand add the followinghttp_proxyenvironment variables there:http_proxy:<value> https_proxy:<value> proxy_username:<value> Proxy_password:<value>
http_proxy:<value> https_proxy:<value> proxy_username:<value> Proxy_password:<value>Copy to Clipboard Copied! Toggle word wrap Toggle overflow Or
- To do this through the UI use the following procedure:
Procedure
- From the navigation panel, select → → .
- Click .
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/"
},
"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/"
},
3.5. Configuring Proxy settings on automation hub Copy linkLink copied to clipboard!
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.ymlfile 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.comcollections: # Install a collection from Ansible Galaxy. - name: community.aws version: 5.2.0 source: https://galaxy.ansible.comCopy to Clipboard Copied! Toggle word wrap Toggle overflow
Procedure
- Log in to Ansible Automation Platform.
- From the navigation panel, select → .
- In the Details tab in the Community remote, click .
-
In the YAML requirements field, paste the contents of your
requirements.ymlfile. - Click .
Result
You can now synchronize collections identified in your requirements.yml file from Ansible Galaxy to your private automation hub.
Next steps
See Synchronizing Ansible content collections in automation hub for syncing steps.
3.6. Configuring proxy settings on Event-Driven Ansible Copy linkLink copied to clipboard!
For Event-Driven Ansible, there are no global settings to set a proxy. You must specify the proxy for every project.
Procedure
- From the navigation panel, select → .
- Click
Use the Proxy field.
3.7. Configuring proxy settings for automation mesh Copy linkLink copied to clipboard!
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 Copy linkLink copied to clipboard!
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 Copy linkLink copied to clipboard!
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 Copy linkLink copied to clipboard!
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
/etc/ansible-automation-platform/gateway/settings.py
4.1.2. Container-based deployments Copy linkLink copied to clipboard!
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 Copy linkLink copied to clipboard!
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 Copy linkLink copied to clipboard!
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 Copy linkLink copied to clipboard!
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
/etc/ansible-automation-platform/gateway/grpc_settings.py
4.2.2. Impacts of modifying the grpc_settings.py file Copy linkLink copied to clipboard!
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 Copy linkLink copied to clipboard!
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:
- Application settings.py: This file is in the application itself and defines the loading order and location of additional settings files.
- 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.
-
Customer override file: The
/etc/ansible-automation-platform/gateway/settings.pyfile is automatically installed and can be used to override any configuration indefaults.py. Changes to this file affect both the API and gRPC servers. -
Application gRPC default settings: After the customer override file, the application loads additional default settings for the gRPC server only from the
grpc_default.pyfile. Specifically, this file includes database OPTIONS for the gRPC server, such as the keepalive parameters. -
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. -
Platform override settings file: Any settings in the
/etc/ansible-automation-platform/settings.pyfile 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. - 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.
Chapter 5. Managing usability analytics and data collection from automation controller Copy linkLink copied to clipboard!
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 Copy linkLink copied to clipboard!
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.
5.1.1. Controlling data collection from automation controller Copy linkLink copied to clipboard!
You can control how automation controller collects data from the → → menu.
Procedure
- Log in to your automation controller.
- From the navigation panel, select → → .
- Select Gather data for Automation Analytics to enable automation controller to gather data on automation and send it to Automation Analytics.
Chapter 6. Renewing and changing the SSL/TLS certificates Copy linkLink copied to clipboard!
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 Copy linkLink copied to clipboard!
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.
6.1.1. Changing TLS certificates and keys using the installation program Copy linkLink copied to clipboard!
The following procedure describes how to update the TLS certificates and keys by using the installation program.
Procedure
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.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 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 Service Certificate file path Key file path Automation controller
~/aap/controller/etc/tower.cert~/aap/controller/etc/tower.keyEvent-Driven Ansible
~/aap/eda/etc/eda.cert~/aap/eda/etc/eda.keyPlatform gateway
~/aap/gateway/etc/gateway.cert~/aap/gateway/etc/gateway.keyAutomation hub
~/aap/hub/etc/pulp.cert~/aap/hub/etc/pulp.keyPostgreSQL
~/aap/postgresql/server.crt~/aap/postgresql/server.keyReceptor
~/aap/receptor/etc/receptor.crt~/aap/receptor/etc/receptor.keyRedis
~/aap/redis/server.crt~/aap/redis/server.key
After preparing your certificates, run the
installplaybook from your installation directory:ansible-playbook -i <inventory_file_name> ansible.containerized_installer.install
ansible-playbook -i <inventory_file_name> ansible.containerized_installer.installCopy to Clipboard Copied! Toggle word wrap Toggle overflow
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/
$ curl -vk https://<hostname_or_ip>:<port_number>/api/v2/
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
* SSL certificate verify OK
6.2. Operator-based installations Copy linkLink copied to clipboard!
6.2.1. Changing the SSL certificate and key on automation controller on OpenShift Container Platform Copy linkLink copied to clipboard!
The following procedure describes how to change the SSL certificate and key for automation controller running on OpenShift Container Platform.
Procedure
- Copy the signed SSL certificate and key to a secure location.
Create a TLS secret within OpenShift:
oc create secret tls ${CONTROLLER_INSTANCE}-certs-$(date +%F) --cert=/path/to/ssl.crt --key=/path/to/ssl.keyoc create secret tls ${CONTROLLER_INSTANCE}-certs-$(date +%F) --cert=/path/to/ssl.crt --key=/path/to/ssl.keyCopy to Clipboard Copied! Toggle word wrap Toggle overflow Modify the automation controller custom resource to add
route_tls_secretand the name of the new secret to the spec section.oc edit automationcontroller/${CONTROLLER_INSTANCE}oc edit automationcontroller/${CONTROLLER_INSTANCE}Copy to Clipboard Copied! Toggle word wrap Toggle overflow ... spec: route_tls_secret: automation-controller-certs-2023-04-06 ...
... spec: route_tls_secret: automation-controller-certs-2023-04-06 ...Copy to Clipboard Copied! Toggle word wrap Toggle overflow
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.
- Wait a few minutes for the changes to be applied.
Verify that new SSL certificate and key have been installed:
true | openssl s_client -showcerts -connect ${CONTROLLER_FQDN}:443true | openssl s_client -showcerts -connect ${CONTROLLER_FQDN}:443Copy to Clipboard Copied! Toggle word wrap Toggle overflow
6.2.2. Changing the SSL certificate and key for automation hub on OpenShift Container Platform Copy linkLink copied to clipboard!
The following procedure describes how to change the SSL certificate and key for automation hub running on OpenShift Container Platform.
Procedure
- Copy the signed SSL certificate and key to a secure location.
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.keyoc create secret tls ${AUTOMATION_HUB_INSTANCE}-certs-$(date +%F) --cert=/path/to/ssl.crt --key=/path/to/ssl.keyCopy to Clipboard Copied! Toggle word wrap Toggle overflow Modify the automation hub custom resource to add
route_tls_secretand the name of the new secret to the spec section.oc edit automationhub/${AUTOMATION_HUB_INSTANCE}oc edit automationhub/${AUTOMATION_HUB_INSTANCE}Copy to Clipboard Copied! Toggle word wrap Toggle overflow ... spec: route_tls_secret: automation-hub-certs-2023-04-06 ...
... spec: route_tls_secret: automation-hub-certs-2023-04-06 ...Copy to Clipboard Copied! Toggle word wrap Toggle overflow
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.
- Wait a few minutes for the changes to be applied.
Verify that new SSL certificate and key have been installed:
true | openssl s_client -showcerts -connect ${CONTROLLER_FQDN}:443true | openssl s_client -showcerts -connect ${CONTROLLER_FQDN}:443Copy to Clipboard Copied! Toggle word wrap Toggle overflow
6.3. RPM-based installations Copy linkLink copied to clipboard!
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.
6.3.1. Renewing the self-signed SSL/TLS certificates Copy linkLink copied to clipboard!
The following steps regenerate new SSL/TLS certificates for all Ansible Automation Platform components.
Procedure
Add
aap_service_regen_cert=trueto the inventory file in the[all:vars]section:[all:vars] aap_service_regen_cert=true
[all:vars] aap_service_regen_cert=trueCopy to Clipboard Copied! Toggle word wrap Toggle overflow - 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
openssl verify -CAfile ansible-automation-platform-managed-ca-cert.crt /etc/ansible-automation-platform/eda/server.cert openssl s_client -connect <EDA_FQDN>:443Copy to Clipboard Copied! Toggle word wrap Toggle overflow 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
openssl verify -CAfile ansible-automation-platform-managed-ca-cert.crt /etc/ansible-automation-platform/gateway/gateway.cert openssl s_client -connect <GATEWAY_FQDN>:443Copy to Clipboard Copied! Toggle word wrap Toggle overflow 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
openssl verify -CAfile ansible-automation-platform-managed-ca-cert.crt /etc/pulp/certs/pulp_webserver.crt openssl s_client -connect <HUB_FQDN>:443Copy to Clipboard Copied! Toggle word wrap Toggle overflow 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
openssl verify -CAfile ansible-automation-platform-managed-ca-cert.crt /etc/tower/tower.cert openssl s_client -connect <CONTROLLER_FQDN>:443Copy to Clipboard Copied! Toggle word wrap Toggle overflow
6.3.2. Changing SSL/TLS certificates and keys using the installation program Copy linkLink copied to clipboard!
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
- Copy the new SSL/TLS certificates and keys to a path relative to the Ansible Automation Platform installer.
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_certNoteThe
custom_ca_certmust be the root certificate authority that signed the intermediate certificate authority. This file is installed in/etc/pki/ca-trust/source/anchors.
-
Event-Driven Ansible controller:
- Run the installation program.
6.3.3. Changing SSL/TLS certificates and keys manually Copy linkLink copied to clipboard!
The following procedure describes how to change SSL/TLS certificates and keys manually for all Ansible Automation Platform components.
Procedure
Backup the current SSL/TLS certificate:
cp <CERT_PATH> <CERT_PATH>-$(date +%F)
cp <CERT_PATH> <CERT_PATH>-$(date +%F)Copy to Clipboard Copied! Toggle word wrap Toggle overflow Backup the current key files:
cp <KEY_PATH> <KEY_PATH>-$(date +%F)
cp <KEY_PATH> <KEY_PATH>-$(date +%F)Copy to Clipboard Copied! Toggle word wrap Toggle overflow - Copy the new SSL/TLS certificate to the certificate path.
- Copy the new key to the key path.
Restore the SELinux context:
restorecon -v <CERT_PATH> <KEY_PATH>
restorecon -v <CERT_PATH> <KEY_PATH>Copy to Clipboard Copied! Toggle word wrap Toggle overflow Set appropriate permissions for the certificate and key files:
chown <OWNER>:<GROUP> <CERT_PATH> <KEY_PATH> chmod 0600 <CERT_PATH> <KEY_PATH>
chown <OWNER>:<GROUP> <CERT_PATH> <KEY_PATH> chmod 0600 <CERT_PATH> <KEY_PATH>Copy to Clipboard Copied! Toggle word wrap Toggle overflow Test the NGINX configuration:
nginx -t
nginx -tCopy to Clipboard Copied! Toggle word wrap Toggle overflow Reload NGINX:
systemctl reload nginx.service
systemctl reload nginx.serviceCopy to Clipboard Copied! Toggle word wrap Toggle overflow Verify that new SSL/TLS certificate and key have been installed:
true | openssl s_client -showcerts -connect <COMPONENT_FQDN>:443
true | openssl s_client -showcerts -connect <COMPONENT_FQDN>:443Copy to Clipboard Copied! Toggle word wrap Toggle overflow Expand Table 6.2. SSL/TLS certificate and key file paths per service Service Certificate file path Key file path Owner:Group Automation controller
/etc/tower/tower.cert/etc/tower/tower.keyroot:awxAutomation hub
/etc/pulp/certs/pulp_webserver.crt/etc/pulp/certs/pulp_webserver.keyroot:pulpEvent-Driven Ansible controller
/etc/ansible-automation-platform/eda/server.cert/etc/ansible-automation-platform/eda/server.keyroot:edaPlatform gateway
/etc/ansible-automation-platform/gateway/gateway.cert/etc/ansible-automation-platform/gateway/gateway.keyroot:gateway