This document describes how Red Hat Ansible Tower handles secrets and connections in a secure fashion.
Ansible Tower manages three sets of secrets:
Ansible Tower hashes local Ansible Tower user passwords with the PBKDF2 algorithm using a SHA256 hash. Users who authenticate via external account mechanisms (LDAP, SAML, OAuth, and others) do not have any password or secret stored.
Ansible Tower contains the following secrets used operationally:
These secrets are all stored unencrypted on the Ansible Tower server, as they are all needed to be read by the Ansible Tower service at startup in an automated fashion. All secrets are protected by Unix permissions, and restricted to root and the Ansible Tower service user awx.
If hiding of these secrets is required, the files that these secrets are read from are interpreted Python. These files can be adjusted to retrieve these secrets via some other mechanism, as long as it will be available at service start. Doing so is a customer provided modification that may need to be reapplied every upgrade. Red Hat Support and Red Hat Consulting has examples of such modifications.
If, for any reason you believe the
SECRET_KEY Tower generated for you has been compromised and needs to be regenerated, you can run a tool from the installer that behaves much like the Tower backup and restore tool. To generate a new secret key:
A backup copy of the prior key is saved in
Ansible Tower stores a variety of secrets in the database that are either used for automation or are a result of automation. These secrets include:
To encrypt secret fields, Tower uses AES in CBC mode with a 256-bit key for encryption, PKCS7 padding, and HMAC using SHA256 for authentication. The encryption/decryption process derives the AES-256 bit encryption key from the SECRET_KEY (described above), 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, Tower fails to correctly decrypt the secret. Ansible Tower is designed such that the SECRET_KEY is never readable in playbooks Ansible Tower launches, that these secrets are never readable by Tower users, and no secret field values are ever made available via the Ansible Tower REST API. If a secret value is used in a playbook, we recommend using no_log on the task so that it is not accidentally logged.
Ansible Tower connects to the following services as part of internal operation:
The connection to memcached is over a local unix socket, restricted to the awx service user.
The connection to the PostgreSQL database is done via password authentication over TCP, either via localhost or remotely (external database). This connection can use PostgreSQL’s built in support for SSL/TLS, as natively configured by the installer support. SSL/TLS protocols are configured by the default OpenSSL configuration.
The connection to the RabbitMQ message bus is locally (Tower -> local RabbitMQ) and remotely (local RabbitMQ to other RabbitMQ cluster members). This connection can use TLS 1.2 natively configured by the installer.
Ansible Tower is accessed via standard HTTP/HTTPS on standard ports, provided by nginx. A self-signed cert/key is installed by default; the customer can provide a locally appropriate certificate and key. SSL/TLS algorithm support is configured in the /etc/nginx/nginx.conf configuration file. An “intermediate” profile is used by default, and can be configured by the customer. Customer changes must be reapplied on each update.
Ansible Tower also connects to managed machines and services as part of automation. All connections to managed machines are done via standard secure mechanism as specified such as SSH, WinRM, SSL/TLS, and so on - each of these inherits configuration from the system configuration for the feature in question (such as the system OpenSSL configuration).