Red Hat SummitUnderstand how Ansible Automation Platform manages secrets
Ansible Automation Platform uses several secrets (passwords, keys, and so on) operationally. These secrets are stored unencrypted on the various Ansible Automation Platform servers, as each component service must read them at startup.
All files are protected by UNIX permissions, and restricted to the root user or the appropriate service account user. These files should be routinely monitored to ensure there has been no unauthorized access or modification.
RPM-based installation secrets
The following table provides the location of these secrets for RPM-based installs of Ansible Automation Platform.
| Automation controller secrets |
|
| File path |
Description |
| |
A secret key used for encrypting automation secrets in the database. If the |
| |
SSL/TLS certificate and key for the automation controller web service. A self-signed For more information, see Installing with user-provided PKI certificates in Installation settings to secure your platform. |
| |
Contains the password used by automation controller to connect to the database, unless TLS authentication is used for the database connection. |
| |
Contains the secret used by automation controller for WebSocket broadcasts. |
| |
Contains the key used by automation controller to sync state with the platform gateway. |
| Platform gateway secrets |
|
| File path |
Description |
| |
A secret key used for encrypting automation secrets in the database. If the |
| |
SSL/TLS certificate for the platform gateway web service. A self-signed certificate is installed by default, although a user-provided certificate and key pair can be used. For more information, see Installing with user-provided PKI certificates in Installation settings to secure your platform. |
| |
SSL/TLS key for the platform gateway web service. automation controller configA self-signed certificate is installed by default, although a user-provided certificate and key pair can be used. For more information, see Installing with user-provided PKI certificates in Installation settings to secure your platform. |
| |
SSL/TLS certificate used for mutual TLS (mTLS) authentication with the Redis cache used by the platform gateway. |
| |
SSL/TLS key used for mutual TLS (mTLS) authentication with the Redis cache used by the platform gateway. |
| |
Contains the password used by the platform gateway to connect to the database, unless TLS authentication is used for the database connection. Also contains the password used to connect to the Redis cache used by the platform gateway. |
| Automation hub secrets |
|
| File path |
Description |
| |
Contains the password used by automation hub to connect to the database, unless TLS authentication is used for the database connection. Contains the Django secret key used by the automation hub web service. |
| |
OpenSSL public key in PEM format for the automation hub EE token authentication. It is generated by default from the |
| |
OpenSSL private key in PEM format for the automation hub EE token authentication. It is generated by default, although a user can provide their own private key with the |
| |
SSL/TLS certificate for the automation hub web service. A self-signed certificate is installed by default, although a user-provided certificate and key pair can be used. For more information, see Installing with user-provided PKI certificates in Installation settings to secure your platform. |
| |
SSL/TLS key for the automation hub web service. A self-signed certificate is installed by default, although a user-provided certificate and key pair can be used. For more information, see Installing with user-provided PKI certificates in Installation settings to secure your platform. |
| |
A key used for encrypting sensitive fields in the automation hub database table. If the key changes or is unknown, automation hub cannot access the encrypted fields in the database. |
| Event-Driven Ansible secrets |
|
| File path |
Description |
| |
A secret key used for encrypting fields in the Event-Driven Ansible controller database table. If the SECRET_KEY changes or is unknown, the Event-Driven Ansible controller cannot access the encrypted fields in the database. |
| |
Contains the password used by the Event-Driven Ansible gateway to connect to the database, unless TLS authentication is used for the database connection. Contains the password used to connect to the Redis cache used by the Event-Driven Ansible controller. Contains the key used by the Event-Driven Ansible controller to sync state with the platform gateway. |
| |
SSL/TLS certificate for the Event-Driven Ansible controller web service. A self-signed certificate is installed by default, although a user-provided certificate and key pair can be used. For more information, see see Installing with user-provided PKI certificates in Installation settings to secure your platform. |
| |
SSL/TLS key for the Event-Driven Ansible controller web service. A self-signed certificate is installed by default, although a user-provided certificate and key pair can be used. For more information, see Installing with user-provided PKI certificates in Installation settings to secure your platform. |
| |
SSL/TLS certificate used for mutual TLS (mTLS) authentication with the Redis cache used by the Event-Driven Ansible controller |
| |
SSL/TLS key used for mutual TLS (mTLS) authentication with the Redis cache used by the Event-Driven Ansible controller |
| |
SSL/TLS certificate for the Event-Driven Ansible controller WebSocket endpoint. A self-signed certificate is installed by default, although a user-provided certificate and key pair can be used. For more information, see Installing with user-provided PKI certificates in Installation settings to secure your platform. |
| |
SSL/TLS key for the Event-Driven Ansible controller WebSocket endpoint. A self-signed certificate is installed by default, although a user-provided certificate and key pair can be used. For more information, see Installing with user-provided PKI certificates in Installation settings to secure your platform. |
| Redis secrets |
|
| File path |
Description |
| |
SSL/TLS certificate for the internal self-signed certificate authority used by the installation program to generate the default self-signed certificates for each component service. |
| |
SSL/TLS key for the internal self-signed certificate authority used by the installation program to generate the default self-signed certificates for each component service. |
Some of these file locations reflect the previous product name of automation controller, formerly named Ansible Tower.
Container-based installation secrets
The secrets listed for RPM-based installations are also used in container-based installations, but they are stored in a different manner. Container-based installations of Red Hat Ansible Automation Platform use Podman secrets to store operational secrets. These secrets can be listed using the podman secret list command.
By default, Podman stores data in the home directory of the user who installed and runs the containerized Red Hat Ansible Automation Platform services. Podman secrets are stored in the file $HOME/.local/share/containers/storage/secrets/filedriver/secretsdata.json as base64-encoded strings, so while they are not in plain text the values are only obfuscated.
The data stored in a Podman secret can be shown using the command podman secret inspect --showsecret <secret>.
This file should be routinely monitored to ensure there has been no unauthorized access or modification.
Automation use secrets
Ansible Automation Platform stores a variety of secrets in the database that are either used for automation or are a result of automation. Automation use secrets include:
- All secret fields of all credential types (passwords, secret keys, authentication tokens, secret cloud credentials).
- Secret tokens and passwords for external services defined in automation controller settings.
- “password” type survey field entries.
You can grant users and teams the ability to use these credentials without actually exposing the credential to the user. This means that if a user moves to a different team or leaves the organization, you do not have to re-key all of your systems.
Ansible Automation Platform uses SSH (or the Windows equivalent) to connect to remote hosts. To pass the key from automation controller to SSH, the key must be decrypted before it can be written to a named pipe. Automation controller then uses that pipe to send the key to SSH (so that it is never written to disk). If passwords are used, automation controller handles those by responding directly to the password prompt and decrypting the password before writing it to the prompt.
As an administrator with superuser access, you can define a custom credential type in a standard format by using a YAML/JSON-like definition. This allows the assignment of new credential types to jobs and inventory updates. This, in turn, lets you to define a custom credential type that works in ways similar to existing credential types. For example, you can create a custom credential type that injects an API token for a third-party web service into an environment variable. Your playbook or custom inventory script can then consume this.
To encrypt secret fields, Ansible Automation Platform uses the Advanced Encryption Standard (AES) in Cipher Block Chaining (CBC) mode with a 256-bit key for encryption, Public-Key cryptography Standard (PKCS7) padding, and Hash-Based Message Authentication Code (HMAC) using SHA256 for authentication. The encryption and decryption processes derive the AES-256 bit encryption key from the SECRET_KEY, the field name of the model field, and the database-assigned auto-incremented record ID. Thus, if any attribute used in the key generation process changes, Ansible Automation Platform fails to correctly decrypt the secret. Ansible Automation Platform is designed such that the SECRET_KEY is never readable in playbooks Ansible Automation Platform launches. This means that these secrets are never readable by Ansible Automation Platform users, and no secret field values are ever made available through the Ansible Automation Platform REST API. If a secret value is used in a playbook, you must use no_log on the task so that it is not accidentally logged.
Protect sensitive data with no_log
If you save Ansible output to a log, you expose any secret data in your Ansible output, such as passwords and usernames. To keep sensitive values out of your logs, mark tasks that expose them with the no_log: True attribute.
However, the no_log attribute does not affect debugging output, so be careful not to debug playbooks in a production environment.
'%20d='M201.5%20305.5c-13.8%200-24.9-11.1-24.9-24.6%200-13.8%2011.1-24.9%2024.9-24.9%2013.6%200%2024.6%2011.1%2024.6%2024.9%200%2013.6-11.1%2024.6-24.6%2024.6zM504%20256c0%20137-111%20248-248%20248S8%20393%208%20256%20119%208%20256%208s248%20111%20248%20248zm-132.3-41.2c-9.4%200-17.7%203.9-23.8%2010-22.4-15.5-52.6-25.5-86.1-26.6l17.4-78.3%2055.4%2012.5c0%2013.6%2011.1%2024.6%2024.6%2024.6%2013.8%200%2024.9-11.3%2024.9-24.9s-11.1-24.9-24.9-24.9c-9.7%200-18%205.8-22.1%2013.8l-61.2-13.6c-3-.8-6.1%201.4-6.9%204.4l-19.1%2086.4c-33.2%201.4-63.1%2011.3-85.5%2026.8-6.1-6.4-14.7-10.2-24.1-10.2-34.9%200-46.3%2046.9-14.4%2062.8-1.1%205-1.7%2010.2-1.7%2015.5%200%2052.6%2059.2%2095.2%20132%2095.2%2073.1%200%20132.3-42.6%20132.3-95.2%200-5.3-.6-10.8-1.9-15.8%2031.3-16%2019.8-62.5-14.9-62.5zM302.8%20331c-18.2%2018.2-76.1%2017.9-93.6%200-2.2-2.2-6.1-2.2-8.3%200-2.5%202.5-2.5%206.4%200%208.6%2022.8%2022.8%2087.3%2022.8%20110.2%200%202.5-2.2%202.5-6.1%200-8.6-2.2-2.2-6.1-2.2-8.3%200zm7.7-75c-13.6%200-24.6%2011.1-24.6%2024.9%200%2013.6%2011.1%2024.6%2024.6%2024.6%2013.8%200%2024.9-11.1%2024.9-24.6%200-13.8-11-24.9-24.9-24.9z'/%3e%3c/svg%3e){kind=small}