Red Hat Ansible Automation Platform operations guide
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.
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!
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 customer 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.
1.1. Activate with credentials Copy linkLink copied to clipboard!
When Ansible Automation Platform launches for the first time, the Ansible Automation Platform Subscription screen automatically displays. You can use your Red Hat credentials to retrieve and import your subscription directly into Ansible Automation Platform.
You are opted in for Automation Analytics by default when you activate the platform on first time log in. This helps Red Hat improve the product by delivering you a much better user experience. You can opt out, after activating Ansible Automation Platform, by doing the following:
- From the navigation panel, select menu:[Settings] and select the Miscellaneous System settings option.
- Click .
- Toggle the Gather data for Automation Analytics switch to the off position.
- Click .
Procedures
- Enter your Red Hat username and password.
Click .
NoteYou can also use your Satellite username and password if your cluster nodes are registered to Satellite through Subscription Manager.
- Review the End User License Agreement and select I agree to the End User License Agreement.
- Click .
- Once your subscription has been accepted, the license screen displays and navigates you to the Dashboard of the Ansible Automation Platform interface. You can return to the license screen by clicking the icon ⚙ and selecting the License option from the Settings screen.
1.2. Activate with a manifest file Copy linkLink copied to clipboard!
If you have a subscriptions manifest, you can upload the manifest file either by using the Red Hat Ansible Automation Platform interface or manually in an Ansible Playbook.
You are opted in for Automation Analytics by default when you activate the platform on first time log in. This helps Red Hat improve the product by delivering you a much better user experience. You can opt out, after activating Ansible Automation Platform, by doing the following:
- From the navigation panel, select menu:[Settings] and select the Miscellaneous System settings option.
- Click .
- Toggle the Gather data for Automation Analytics switch to the off position.
- Click .
Prerequisites
You must have a Red Hat Subscription Manifest file exported from the Red Hat Customer Portal. For more information, see Obtaining a manifest file.
Uploading with the interface
- Complete steps to generate and download the manifest file
- Log in to Red Hat Ansible Automation Platform.
- If you are not immediately prompted for a manifest file, go to and select the License option.
- Make sure the Username and Password fields are empty.
- Click and select the manifest file.
- Click .
- Review the End User License Agreement and select I agree to the End User License Agreement.
- Click .
- Once your subscription has been accepted, the license screen displays and navigates you to the Dashboard of the Ansible Automation Platform interface. You can return to the license screen by clicking the icon ⚙ and selecting the License option from the Settings screen.
If the button is disabled on the License page, clear the USERNAME and PASSWORD fields.
Uploading manually
If you are unable to apply or update the subscription information by using the Red Hat Ansible Automation Platform interface, you can upload the subscriptions manifest manually in an Ansible Playbook by using the license module in the ansible.controller collection.
- name: Set the license using a file license: manifest: "/tmp/my_manifest.zip"
- name: Set the license using a file
license:
manifest: "/tmp/my_manifest.zip"
Chapter 2. Obtaining a manifest file Copy linkLink copied to clipboard!
You can obtain a subscription manifest in the Subscription Allocations section of Red Hat Subscription Management. After you obtain a subscription allocation, you can download its manifest file and upload it to activate Ansible Automation Platform.
To begin, login to the Red Hat Customer Portal using your administrator user account and follow the procedures in this section.
2.1. Create a subscription allocation Copy linkLink copied to clipboard!
Creating a new subscription allocation allows you to set aside subscriptions and entitlements for a system that is currently offline or air-gapped. This is necessary before you can download its manifest and upload it to Ansible Automation Platform.
Procedure
- From the Subscription Allocations page, click .
- Enter a name for the allocation so that you can find it later.
- Select Type: Satellite 6.8 as the management application.
- Click .
2.2. Adding subscriptions to a subscription allocation Copy linkLink copied to clipboard!
Once an allocation is created, you can add the subscriptions you need for Ansible Automation Platform to run properly. This step is necessary before you can download the manifest and add it to Ansible Automation Platform.
Procedure
- From the Subscription Allocations page, click on the name of the Subscription Allocation to which you would like to add a subscription.
- Click the Subscriptions tab.
- Click .
- Enter the number of Ansible Automation Platform Entitlement(s) you plan to add.
- Click .
Verification
After your subscription has been accepted, subscription details are displayed. A status of Compliant indicates your subscription is in compliance with the number of hosts you have automated within your subscription count. Otherwise, your status will show as Out of Compliance, indicating you have exceeded the number of hosts in your subscription.
Other important information displayed include the following:
- Hosts automated
- Host count automated by the job, which consumes the license count
- Hosts imported
- Host count considering all inventory sources (does not impact hosts remaining)
- Hosts remaining
- Total host count minus hosts automated
2.3. Downloading a manifest file Copy linkLink copied to clipboard!
After an allocation is created and has the appropriate subscriptions on it, you can download the manifest from Red Hat Subscription Management.
Procedure
- From the Subscription Allocations page, click on the name of the Subscription Allocation to which you would like to generate a manifest.
- Click the Subscriptions tab.
- Click to download the manifest file.
The file is saved to your default downloads folder and can now be uploaded to activate Red Hat Ansible Automation Platform.
Chapter 3. Post-installation steps Copy linkLink copied to clipboard!
Whether you are a new Ansible Automation Platform user looking to start automating, or an existing administrator looking to migrate old Ansible content to your latest installed version of Red Hat Ansible Automation Platform, explore the next steps to begin using the new features of Ansible Automation Platform 2.4.
3.1. Steps to migrate data to Ansible Automation Platform 2.4 Copy linkLink copied to clipboard!
For platform administrators looking to complete an upgrade to the Ansible Automation Platform 2.4, there may be additional steps needed to migrate data to a new instance:
To complete an upgrade to Ansible Automation Platform 2.4, you must migrate your data. Migrating data to a new instance requires additional steps.
3.1.1. Migrating from legacy virtual environments (venvs) to automation execution environments Copy linkLink copied to clipboard!
Ansible Automation Platform 2.4 moves you away from custom Python virtual environments (venvs) in favor of automation execution environments - containerized images that package the necessary components needed to run and scale your Ansible automation. These components include ansible-core, Ansible Content Collections, Python dependencies, Red Hat Enterprise Linux UBI 8, and any additional package dependencies.
To migrate your venvs to execution environments, you must use the awx-manage command to list and export a list of venvs from your original instance, and then use ansible-builder to create execution environments.
3.1.2. Migrating Ansible Engine images using Ansible Builder Copy linkLink copied to clipboard!
To migrate previous Ansible Engine images for use with Ansible Automation Platform 2.4, use the ansible-builder tool to automate the process of rebuilding images (including its custom plugins and dependencies) for use with automation execution environments.
3.1.3. Migrating to Ansible Core 2.13 Copy linkLink copied to clipboard!
When upgrading to ansible-core 2.13, you must update your playbooks and plugins, or other parts of your Ansible infrastructure to be supported by the latest version of ansible-core.
3.2. Updating execution environment image locations Copy linkLink copied to clipboard!
If you installed private automation hub separately from Ansible Automation Platform, you can update your execution environment image locations to point to your private automation hub.
Procedure
-
Go to the directory that contains
setup.sh Create
./group_vars/automationcontrollerby running the following command:touch ./group_vars/automationcontroller
touch ./group_vars/automationcontrollerCopy to Clipboard Copied! Toggle word wrap Toggle overflow Paste the following content into
./group_vars/automationcontroller. Adjust the settings to fit your environment:Copy to Clipboard Copied! Toggle word wrap Toggle overflow Run the
./setup.shscript./setup.sh
$ ./setup.shCopy to Clipboard Copied! Toggle word wrap Toggle overflow
Verification
- Log in to Ansible Automation Platform as a user with system administrator access.
- Go to → .
-
In the Image column, confirm that the execution environment image location has changed from the default value of
<registry url>/ansible-automation-platform-<version>/<image name>:<tag>to<automation hub url>/<image name>:<tag>.
3.3. Benefits of automation mesh Copy linkLink copied to clipboard!
The automation mesh component of the Red Hat Ansible Automation Platform simplifies the process of distributing automation across multi-site deployments. For enterprises with multiple isolated IT environments, automation mesh provides a consistent and reliable way to deploy and scale up automation across your execution nodes using a peer-to-peer mesh communication network.
When upgrading from version 1.x to the latest version of Ansible Automation Platform, you must migrate the data from your legacy isolated nodes into execution nodes necessary for automation mesh. You can implement automation mesh by planning out a network of hybrid and control nodes, then editing the inventory file found in the Ansible Automation Platform installer to assign mesh-related values to each of your execution nodes.
Chapter 4. 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.
4.1. Enable proxy support Copy linkLink copied to clipboard!
To provide proxy server support, automation controller handles proxied requests (such as ALB, NLB , HAProxy, Squid, Nginx and tinyproxy in front of automation controller) via 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
- On your automation controller, navigate to .
- Select Miscellaneous System settings from the list of System options.
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
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.
4.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 using the PROXY_IP_ALLOWED_LIST field in the settings menu on your automation controller. Load balancers and hosts that are not on the known proxies list will result in a rejected request.
4.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 settings page for your automation controller.
Procedure
- On your automation controller, navigate to and select Miscellaneous System settings from the list of System options.
In the PROXY_IP_ALLOWED_LIST field, enter IP addresses that are allowed to connect to your automation controller, following the syntax in the example below:
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
-
PROXY_IP_ALLOWED_LISTrequires proxies in the list are properly sanitizing header input and correctly setting anX-Forwarded-Forvalue equal to the real source IP of the client. Automation controller can rely on the IP addresses and hostnames inPROXY_IP_ALLOWED_LISTto provide non-spoofed values for theX-Forwarded-Forfield. 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.
4.3. Configuring a reverse proxy Copy linkLink copied to clipboard!
You can support a reverse proxy server configuration by adding HTTP_X_FORWARDED_FOR to the REMOTE_HOST_HEADERS field in your automation controller 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
- On your automation controller, navigate to and select Miscellaneous System settings from the list of System options.
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 = True
4.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.
Disclaimer: Links contained in this note to external websites 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.
Chapter 5. Configuring automation controller websocket connections Copy linkLink copied to clipboard!
You can configure automation controller in order to align the websocket configuration with your nginx or load balancer configuration.
5.1. Websocket configuration for automation controller Copy linkLink copied to clipboard!
Automation controller nodes are interconnected through websockets to distribute all websocket-emitted messages throughout your system. This configuration setup enables any browser client websocket to subscribe to any job that might be running on any automation controller node. Websocket clients are not routed to specific automation controller nodes. Instead, any automation controller node can handle any websocket request and each automation controller node must know about all websocket messages destined for all clients.
You can configure websockets at /etc/tower/conf.d/websocket_config.py in all of your automation controller nodes and the changes will be effective after the service restarts.
Automation controller automatically handles discovery of other automation controller nodes through the Instance record in the database.
Your automation controller nodes are designed to broadcast websocket traffic across a private, trusted subnet (and not the open Internet). Therefore, if you turn off HTTPS for websocket broadcasting, the websocket traffic, composed mostly of Ansible playbook stdout, is sent unencrypted between automation controller nodes.
5.1.1. Configuring automatic discovery of other automation controller nodes Copy linkLink copied to clipboard!
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 and protocol, and confirm whether to verify certificates with
TrueorFalsewhen establishing the websocket connections:BROADCAST_WEBSOCKET_PROTOCOL = 'http' BROADCAST_WEBSOCKET_PORT = 80 BROADCAST_WEBSOCKET_VERIFY_CERT = False
BROADCAST_WEBSOCKET_PROTOCOL = 'http' BROADCAST_WEBSOCKET_PORT = 80 BROADCAST_WEBSOCKET_VERIFY_CERT = FalseCopy to Clipboard Copied! Toggle word wrap Toggle overflow Restart automation controller with the following command:
automation-controller-service restart
$ automation-controller-service restartCopy to Clipboard Copied! Toggle word wrap Toggle overflow
Chapter 6. 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.
6.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.
6.1.1. Controlling data collection from automation controller Copy linkLink copied to clipboard!
You can control how automation controller collects data by setting your participation level in the User Interface tab in the Settings menu.
Procedure
- Log in to your automation controller.
- Navigate to and select User Interface settings from the User Interface option.
Select the desired level of data collection from the User Analytics Tracking State drop-down list:
- Off: Prevents any data collection.
- Anonymous: Enables data collection without your specific user data.
- Detailed: Enables data collection including your specific user data.
- Click to apply the settings or to discard the changes.
Chapter 7. Encrypting plaintext passwords in automation controller configuration files Copy linkLink copied to clipboard!
Passwords stored in automation controller configuration files are stored in plain text. A user with access to the /etc/tower/conf.d/ directory can view the passwords used to access the database. Access to the directories is controlled with permissions, so they are protected, but some security findings deem this protection to be inadequate. The solution is to encrypt the passwords individually.
7.1. Creating PostgreSQL password hashes Copy linkLink copied to clipboard!
Procedure
On your automation controller node, run the following:
awx-manage shell_plus
# awx-manage shell_plusCopy to Clipboard Copied! Toggle word wrap Toggle overflow Then run the following from the python prompt:
>>> from awx.main.utils import encrypt_value, get_encryption_key \ >>> postgres_secret = encrypt_value('$POSTGRES_PASS') \ >>> print(postgres_secret)>>> from awx.main.utils import encrypt_value, get_encryption_key \ >>> postgres_secret = encrypt_value('$POSTGRES_PASS') \ >>> print(postgres_secret)Copy to Clipboard Copied! Toggle word wrap Toggle overflow NoteReplace the
$POSTGRES_PASSvariable with the actual plain text password you want to encrypt.The output should resemble the following:
$encrypted$UTF8$AESCBC$Z0FBQUFBQmtLdGNRWXFjZGtkV1ZBR3hkNGVVbFFIU3hhY21UT081eXFkR09aUWZLcG9TSmpndmZYQXFyRHVFQ3ZYSE15OUFuM1RHZHBqTFU3S0MyNEo2Y2JWUURSYktsdmc9PQ==
$encrypted$UTF8$AESCBC$Z0FBQUFBQmtLdGNRWXFjZGtkV1ZBR3hkNGVVbFFIU3hhY21UT081eXFkR09aUWZLcG9TSmpndmZYQXFyRHVFQ3ZYSE15OUFuM1RHZHBqTFU3S0MyNEo2Y2JWUURSYktsdmc9PQ==Copy to Clipboard Copied! Toggle word wrap Toggle overflow Copy the full values of these hashes and save them.
The hash value begins with
$encrypted$, and is not just the string of characters, as shown in the following example:$encrypted$AESCBC$Z0FBQUFBQmNONU9BbGQ1VjJyNDJRVTRKaFRIR09Ib2U5TGdaYVRfcXFXRjlmdmpZNjdoZVpEZ21QRWViMmNDOGJaM0dPeHN2b194NUxvQ1M5X3dSc1gxQ29TdDBKRkljWHc9PQ==
$encrypted$AESCBC$Z0FBQUFBQmNONU9BbGQ1VjJyNDJRVTRKaFRIR09Ib2U5TGdaYVRfcXFXRjlmdmpZNjdoZVpEZ21QRWViMmNDOGJaM0dPeHN2b194NUxvQ1M5X3dSc1gxQ29TdDBKRkljWHc9PQ==Copy to Clipboard Copied! Toggle word wrap Toggle overflow Note that the
$*_PASSvalues are already in plain text in your inventory file.
These steps supply the hash values that replace the plain text passwords within the automation controller configuration files.
7.2. Encrypting the Postgres password Copy linkLink copied to clipboard!
The following procedure replaces the plain text passwords with encrypted values. Perform the following steps on each node in the cluster:
Procedure
Edit
/etc/tower/conf.d/postgres.pyusing:vim /etc/tower/conf.d/postgres.py
$ vim /etc/tower/conf.d/postgres.pyCopy to Clipboard Copied! Toggle word wrap Toggle overflow Add the following line to the top of the file.
from awx.main.utils import decrypt_value, get_encryption_key
from awx.main.utils import decrypt_value, get_encryption_keyCopy to Clipboard Copied! Toggle word wrap Toggle overflow Remove the password value listed after 'PASSWORD': and replace it with the following line, replacing the supplied value of
$encrytpted..with your own hash value:decrypt_value(get_encryption_key('value'),'$encrypted$AESCBC$Z0FBQUFBQmNONU9BbGQ1VjJyNDJRVTRKaFRIR09Ib2U5TGdaYVRfcXFXRjlmdmpZNjdoZVpEZ21QRWViMmNDOGJaM0dPeHN2b194NUxvQ1M5X3dSc1gxQ29TdDBKRkljWHc9PQ=='),decrypt_value(get_encryption_key('value'),'$encrypted$AESCBC$Z0FBQUFBQmNONU9BbGQ1VjJyNDJRVTRKaFRIR09Ib2U5TGdaYVRfcXFXRjlmdmpZNjdoZVpEZ21QRWViMmNDOGJaM0dPeHN2b194NUxvQ1M5X3dSc1gxQ29TdDBKRkljWHc9PQ=='),Copy to Clipboard Copied! Toggle word wrap Toggle overflow NoteThe hash value in this step is the output value of
postgres_secret.The full
postgres.pyresembles the following:Ansible Automation platform controller database settings. from awx.main.utils import decrypt_value, get_encryption_key DATABASES = { 'default': { 'ATOMIC_REQUESTS': True, 'ENGINE': 'django.db.backends.postgresql', 'NAME': 'awx', 'USER': 'awx', 'PASSWORD': decrypt_value(get_encryption_key('value'),'$encrypted$AESCBC$Z0FBQUFBQmNONU9BbGQ1VjJyNDJRVTRKaFRIR09Ib2U5TGdaYVRfcXFXRjlmdmpZNjdoZVpEZ21QRWViMmNDOGJaM0dPeHN2b194NUxvQ1M5X3dSc1gxQ29TdDBKRkljWHc9PQ=='), 'HOST': '127.0.0.1', 'PORT': 5432, } }# Ansible Automation platform controller database settings. from awx.main.utils import decrypt_value, get_encryption_key DATABASES = { 'default': { 'ATOMIC_REQUESTS': True, 'ENGINE': 'django.db.backends.postgresql', 'NAME': 'awx', 'USER': 'awx', 'PASSWORD': decrypt_value(get_encryption_key('value'),'$encrypted$AESCBC$Z0FBQUFBQmNONU9BbGQ1VjJyNDJRVTRKaFRIR09Ib2U5TGdaYVRfcXFXRjlmdmpZNjdoZVpEZ21QRWViMmNDOGJaM0dPeHN2b194NUxvQ1M5X3dSc1gxQ29TdDBKRkljWHc9PQ=='), 'HOST': '127.0.0.1', 'PORT': 5432, } }Copy to Clipboard Copied! Toggle word wrap Toggle overflow
7.3. Restarting automation controller services Copy linkLink copied to clipboard!
Procedure
When encryption is completed on all nodes, perform a restart of services across the cluster using:
automation-controller-service restart
# automation-controller-service restartCopy to Clipboard Copied! Toggle word wrap Toggle overflow - Navigate to the UI, and verify you are able to run jobs across all nodes.
Chapter 8. Renewing and changing the SSL certificate Copy linkLink copied to clipboard!
If your current SSL certificate has expired or will expire soon, you can either renew or replace the SSL certificate used by Ansible Automation Platform.
You must renew the SSL certificate if you need to regenerate the SSL certificate with new information such as new hosts.
You must replace the SSL certificate if you want to use an SSL certificate signed by an internal certificate authority.
8.1. Renewing the self-signed SSL certificate Copy linkLink copied to clipboard!
The following steps regenerate a new SSL certificate for both automation controller and automation hub.
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 server.crt file on automation controller:
openssl verify -CAfile ansible-automation-platform-managed-ca-cert.crt /etc/tower/tower.cert openssl s_client -connect <AUTOMATION_HUB_URL>:443
openssl verify -CAfile ansible-automation-platform-managed-ca-cert.crt /etc/tower/tower.cert
openssl s_client -connect <AUTOMATION_HUB_URL>:443
- Validate the CA file and server.crt file on automation hub:
openssl verify -CAfile ansible-automation-platform-managed-ca-cert.crt /etc/pulp/certs/pulp_webserver.crt openssl s_client -connect <AUTOMATION_CONTROLLER_URL>:443
openssl verify -CAfile ansible-automation-platform-managed-ca-cert.crt /etc/pulp/certs/pulp_webserver.crt
openssl s_client -connect <AUTOMATION_CONTROLLER_URL>:443
8.2. Changing SSL certificates Copy linkLink copied to clipboard!
To change the SSL certificate, you can edit the inventory file and run the installer. The installer verifies that all Ansible Automation Platform components are working. The installer can take a long time to run.
Alternatively, you can change the SSL certificates manually. This is quicker, but there is no automatic verification.
Red Hat recommends that you use the installer to make changes to your Ansible Automation Platform instance.
8.2.1. Prerequisites Copy linkLink copied to clipboard!
- If there is an intermediate certificate authority, you must append it to the server certificate.
- Both automation controller and automation hub use NGINX so the server certificate must be in PEM format.
- 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.
8.2.2. Changing the SSL certificate and key using the installer Copy linkLink copied to clipboard!
The following procedure describes how to change the SSL certificate and key in the inventory file.
Procedure
- Copy the new SSL certificates and keys to a path relative to the Ansible Automation Platform installer.
Add the absolute paths of the SSL certificates and keys to the inventory file. Refer to the Automation controller variables, Automation hub variables, and Event-Driven Ansible controller variables sections of the Red Hat Ansible Automation Platform Installation Guide for guidance on setting these variables.
-
Automation controller:
web_server_ssl_cert,web_server_ssl_key,custom_ca_cert -
Automation hub:
automationhub_ssl_cert,automationhub_ssl_key,custom_ca_cert -
Event-Driven Ansible controller:
automationedacontroller_ssl_cert,automationedacontroller_ssl_key,custom_ca_cert
NoteThe
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.-
Automation controller:
- Run the installer.
8.2.3. Changing the SSL certificate manually Copy linkLink copied to clipboard!
8.2.3.1. Changing the SSL certificate and key manually on automation controller Copy linkLink copied to clipboard!
The following procedure describes how to change the SSL certificate and key manually on Automation Controller.
Procedure
Backup the current SSL certificate:
cp /etc/tower/tower.cert /etc/tower/tower.cert-$(date +%F)
cp /etc/tower/tower.cert /etc/tower/tower.cert-$(date +%F)Copy to Clipboard Copied! Toggle word wrap Toggle overflow Backup the current key files:
cp /etc/tower/tower.key /etc/tower/tower.key-$(date +%F)+
cp /etc/tower/tower.key /etc/tower/tower.key-$(date +%F)+Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
Copy the new SSL certificate to
/etc/tower/tower.cert. -
Copy the new key to
/etc/tower/tower.key. Restore the SELinux context:
restorecon -v /etc/tower/tower.cert /etc/tower/tower.key
restorecon -v /etc/tower/tower.cert /etc/tower/tower.keyCopy to Clipboard Copied! Toggle word wrap Toggle overflow Set appropriate permissions for the certificate and key files:
chown root:awx /etc/tower/tower.cert /etc/tower/tower.key chmod 0600 /etc/tower/tower.cert /etc/tower/tower.key
chown root:awx /etc/tower/tower.cert /etc/tower/tower.key chmod 0600 /etc/tower/tower.cert /etc/tower/tower.keyCopy 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 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
8.2.3.2. 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
8.2.3.3. Changing the SSL certificate and key on Event-Driven Ansible controller Copy linkLink copied to clipboard!
The following procedure describes how to change the SSL certificate and key manually on Event-Driven Ansible controller.
Procedure
Backup the current SSL certificate:
cp /etc/ansible-automation-platform/eda/server.cert /etc/ansible-automation-platform/eda/server.cert-$(date +%F)
cp /etc/ansible-automation-platform/eda/server.cert /etc/ansible-automation-platform/eda/server.cert-$(date +%F)Copy to Clipboard Copied! Toggle word wrap Toggle overflow Backup the current key files:
cp /etc/ansible-automation-platform/eda/server.key /etc/ansible-automation-platform/eda/server.key-$(date +%F)
cp /etc/ansible-automation-platform/eda/server.key /etc/ansible-automation-platform/eda/server.key-$(date +%F)Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
Copy the new SSL certificate to
/etc/ansible-automation-platform/eda/server.cert. -
Copy the new key to
/etc/ansible-automation-platform/eda/server.key. Restore the SELinux context:
restorecon -v /etc/ansible-automation-platform/eda/server.cert /etc/ansible-automation-platform/eda/server.key
restorecon -v /etc/ansible-automation-platform/eda/server.cert /etc/ansible-automation-platform/eda/server.keyCopy to Clipboard Copied! Toggle word wrap Toggle overflow Set appropriate permissions for the certificate and key files:
chown root:eda /etc/ansible-automation-platform/eda/server.cert /etc/ansible-automation-platform/eda/server.key
chown root:eda /etc/ansible-automation-platform/eda/server.cert /etc/ansible-automation-platform/eda/server.keyCopy to Clipboard Copied! Toggle word wrap Toggle overflow chmod 0600 /etc/ansible-automation-platform/eda/server.cert /etc/ansible-automation-platform/eda/server.key
chmod 0600 /etc/ansible-automation-platform/eda/server.cert /etc/ansible-automation-platform/eda/server.keyCopy 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 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
8.2.3.4. Changing the SSL certificate and key manually on automation hub Copy linkLink copied to clipboard!
The following procedure describes how to change the SSL certificate and key manually on automation hub.
Procedure
Backup the current SSL certificate:
cp /etc/pulp/certs/pulp_webserver.crt /etc/pulp/certs/pulp_webserver.crt-$(date +%F)
cp /etc/pulp/certs/pulp_webserver.crt /etc/pulp/certs/pulp_webserver.crt-$(date +%F)Copy to Clipboard Copied! Toggle word wrap Toggle overflow Backup the current key files:
cp /etc/pulp/certs/pulp_webserver.key /etc/pulp/certs/pulp_webserver.key-$(date +%F)
cp /etc/pulp/certs/pulp_webserver.key /etc/pulp/certs/pulp_webserver.key-$(date +%F)Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
Copy the new SSL certificate to
/etc/pulp/certs/pulp_webserver.crt. -
Copy the new key to
/etc/pulp/certs/pulp_webserver.key. Restore the SELinux context:
restorecon -v /etc/pulp/certs/pulp_webserver.crt /etc/pulp/certs/pulp_webserver.key
restorecon -v /etc/pulp/certs/pulp_webserver.crt /etc/pulp/certs/pulp_webserver.keyCopy to Clipboard Copied! Toggle word wrap Toggle overflow Set appropriate permissions for the certificate and key files:
chown root:pulp /etc/pulp/certs/pulp_webserver.crt /etc/pulp/certs/pulp_webserver.key
chown root:pulp /etc/pulp/certs/pulp_webserver.crt /etc/pulp/certs/pulp_webserver.keyCopy to Clipboard Copied! Toggle word wrap Toggle overflow chmod 0600 /etc/pulp/certs/pulp_webserver.crt /etc/pulp/certs/pulp_webserver.key
chmod 0600 /etc/pulp/certs/pulp_webserver.crt /etc/pulp/certs/pulp_webserver.keyCopy 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 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