Easy Read Time: 3 Minutes

Ansible Tower Security Best Practices

Red Hat Ansible Tower is an easy-to-use internet hub to automate continuous configurations and deployments across multiple machines. With features such as centralized management of Ansible Playbooks, clustering, REST API, and role-based access control, Ansible Tower meets the requirements of enterprise users. While the tool comes with a default secure configuration, it is critical to follow best practices to ensure security while managing operating system environments, automation, and automation platforms.

Follow these security best practices to ensure secure automation using Ansible Tower.

Host Operating System

Your Ansible Tower instance is only as secure as your underlying system. Use the security guide specific to your Operating System release to secure your system. Use the links below to find out how to secure BIOS, use cryptographic policies and cryptographic hardware for your application, as well as take other necessary measures to harden the security.

Application

For a secure automation environment, Red Hat recommends that you have the latest stable release of Ansible and Ansible Tower so that bug fixes are available and previous vulnerabilities resolved.

Multiple Ansible Tower clusters

As a security best practice, consider deploying multiple Ansible Tower clusters so that each system can be separate, and no single administrator can have access to all the systems. Each department can have its own Ansible Tower installation to ensure full control.

Multi-organization setup

Additionally, when setting up your instance, Tower automatically creates a default organization under which you can assign users, teams, projects, and inventories. However, you can harden the security further by creating a multi-organization setup, where organization administrators can create additional objects within their respective organization. With this setup, you do not require a super admin user for daily operations, and you can securely store the password.

Minimum administrative accounts

For a secure Tower system, it is crucial to keep the number of administrative accounts to a minimum. Limit the number of people/accounts with root access. Avoid giving sudo or awx to untrusted users as it is equivalent to giving full root access to your system. As a best practice, restrict system administrators for low-level Tower configuration and disaster recovery only.

Minimize local system access

Except for administrative requirements, your Ansible Tower instance does not require local user access. As such, ensure that non-administrators do not have access to the local user to reduce the possibility of hacks.

Use different keys/credentials for each automation piece

Our automation may require accessing the Tower system at different levels. To ensure better security, you can use different keys or credentials for each piece to minimize the vulnerability of any single key or credentials.

Services/Ports

Ansible Tower uses the following Ports and instances:

  • 80, 443 (normal Tower ports)
  • 22 (SSH)
  • 5432 (when the database is installed on an external instance)

Clustering/RabbitMQ ports:

  • 4369, 25672 (used by RabbitMQ to maintain a cluster)
  • 15672 (only required if the RabbitMQ Management Interface is enabled)

Logging and Auditing

For a secure environment, it is also essential that you regularly monitor administrative actions. For your overall RHEL system, you can use the built-in audit support. For Ansible Tower, this is achievable through built-in Activity Stream support.

As a best practice, prefer collecting logging and auditing centrally rather than on your local system. Use the Logging feature in Ansible Tower to send detailed logs to third-party logging aggregator services like Splunk, Loggly, Sumologic, and Elastic Stack, and quickly analyze events in the infrastructure, monitor anomalies, and other technology trends.

Find out the process to integrate these data logging aggregators with your Ansible Tower instance here.

Permissions

Ansible Tower comes with built-in Role-Based Access Controls (RBAC) that allows administrators to centrally manage credentials, define specific roles for each user, and assign specific capabilities to these roles. Find out how you can apply RBAC for your instance, and some of the common roles Tower Organization can manage using the Ansible Tower documentation.

Third-Party Security

Apart from the built-in security hardening features, you can also integrate third-party tools to your Ansible Tower instance and secure automation environments. Some of the popular integrations include:

CyberArk Conjur

The CyberArk Conjur integration allows DevOps and security teams to manage secrets used by CI/CD tools securely and automatically. You can even enable automatic storing and securing secrets for new applications, scripts, and systems to automatically scale protection in your dynamic IT environment. In addition to securing, Conjur also rotates the secrets used by Tower and enables monitored privileged user access to the Ansible console.

https://www.ansible.com/integrations/devops-tools/cyberark

CyberArk Application Identity Manager (AIM)

This Application Identity Manager from CyberArk is useful for securing and managing passwords, SSH keys, and other credentials in Tower. The tool replaces hard-coded credentials with an API call to the vault that automatically stores and rotates the credentials.

Hashicorp Vault

Similar to CyberArk Conjur, Hashicorp Vault allows you to store, access, and distribute secrets based on trusted sources of application and user identity.

Azure Key Vault

Another secret management tool from Microsoft that provides secure storage and access to secrets required by your automation environment. Since Azure Key Vault is a PaaS solution, there is the minimum effort required to manage.

Refer to the Ansible Tower documentation to find out how you can configure and link secret lookups for these third-party solutions.

Known Vulnerabilities

  • CVE-2019-3869: Ansible Tower version before 3.4.3 running on OpenShift or Kubernetes exposes application credentials to playbook job runs through environment variables. A malicious user with access to write playbooks can use this vulnerability to gain admin privileges.
  • CVE-2019-14890: Red Hat Subscription Management (RHSM) credentials saved in plain text in the database after applying Ansible Tower license. A malicious user with access to this information can modify licenses and make other changes.
  • CVE-2019-19342: In Ansible Tower, versions 3.6.x before 3.6.2 and 3.5.x before 3.5.4, a flaw was found when /websocket is requested, and the password contains the ‘#’ character. The request causes a socket error in RabbitMQ when parsing the password along with an HTTP error code 500 while disclosing a password partially in plaintext. An attacker could easily guess some predictable passwords or brute force the password.

Find a complete list of vulnerabilities here.

References:

https://www.ansible.com/products/tower#towerfeatures

https://docs.ansible.com/ansible-tower/latest/html/administration/security_best_practices.html

https://docs.ansible.com/ansible-tower/latest/html/userguide/best_practices.html

https://docs.ansible.com/ansible-tower/3.6.3/html/userguide/security.html#rbac-ug

https://docs.ansible.com/ansible-tower/latest/html/administration/logging.html#ag-logging

https://docs.ansible.com/ansible-tower/2.2.2/html/installandreference/requirements_refguide.html

https://www.cyberark.com/products/privileged-account-security-solution/application-access-manager

https://docs.ansible.com/ansible-tower/3.5.0/html/administration/credential_plugins.html#configure-and-link-secret-lookups

https://www.ansible.com/integrations/devops-tools/cyberark

https://docs.microsoft.com/en-us/azure/key-vault/basic-concepts