About centralized management
Ansible is by design a decentralized management tool. Users can install Ansible on any supported operating system and run ansible-playbook to manage IT systems like servers, network devices and storages. Assuming one knows the proper credentials and has the necessary network access, any accessible device can be managed. This is great to get things started and people new to Ansible appreciate the fact of a smooth learning curve and some quick results.
Large enterprises on the other hand, often see this as a security and compliance risk. Since there is no Role Based Access Control (RBAC), no centralized logging and auditing, and no organized credential management, it is hard to have control over who does what, when, where and with which credentials and privileges.
Ansible Tower which is part of the Ansible Automation Platform is Red Hat’s supported product built from the AWX project. It provides centralized management for Ansible Playbooks, offers a REST API, clustering features, RBAC, credential separation and much more, addressing the requirements of enterprise users.
The problem
There are many centralized management tools we know. Centralized user directories, system management tools, software distributions systems and many other examples share the same design principals. What they all have in common is the fact that an administrator does and can have access to any of the managed systems. Although there are measurements in most of these systems to limit what an administrator can do, there are also often ways to go around them.
If one has control over the Active Directory, it is possible to gain access to all systems managed by this directory. With administrator privileges to a system management tool configuration changes can be rolled out to all managed nodes. Having control over the software distribution system, gives the power to deploy any software on any device. This is what those systems are designed to do and is the desired functionality.
Ansible Tower is no different here. If one has admin privileges in the root organization, there is no limit on what can be done. Due to the nature of this role an administrator has access to all credentials, inventories and managed nodes. This can be a risk since an attacker might try to get access to this account or an frustrated administrator can execute harmful playbooks.
Ansible Tower Security
Since security is such an important topic, the Ansible Tower documentation has a dedicated chapter on security best practices. This gives some background on how Ansible Tower works, where and how sensitive data is stored and provides recommendations to mitigate security risks.
The scenario
For the purpose of this article lets design a solution for a large enterprise customer with several departments and sub organizations. There are different teams: the networking team manages network devices, the database team manages database servers, and the application team only application servers. They should be separated so an admin from one department can not have access to any system managed by the other departments.
Team) --> netdev(Network Device); sysdb(System Operator Database
Team) --> dbserver(Database Servers); sysapp(System Operator Application
Team) --> appserver(Application Servers);
Separate Ansible Tower Clusters
A very simple and probably obvious way to address this, is to deploy multiple Ansible Tower clusters. Each department or internal organization could have their own Ansible Tower installation which they have full control on.
To simplify management the configuration of Ansible Tower should also be done by using Ansible Playbooks. Ansible provides a list of Ansible Tower modules to simplify this task. In rare cases where no module exists, the REST API can be used.
Team) --> netdev(Network Device); end; subgraph Tower Cluster Database Team; sysdb(System Operator Database
Team) --> dbserver(Database Servers); end; subgraph Tower Cluster Application< Team; sysapp(System Operator Application
Team) --> appserver(Application Servers); end;
Pro
Since the Ansible Tower clusters are setup and operated completely isolated, there is no interaction between them and hence it should be impossible to gain access from one to the other. Security could be even further improved by deploying the Ansible Tower clusters into different network segments.
To get an overview of all cluser and to simplify management Automation Analytics provides a SaaS feature where customers can register their Ansible Tower clusters and get an overview and additional details of each cluster.
Con
Having multiple Ansible Tower clusters requires more maintenance efforts. They all need to be installed, managed, regularly updated, monitored and backed up. Some of this can be simplified by using Ansible Playbooks.
Multi-Organization setup
During the installation of Ansible Tower a “default” organization is created. Additional organizations can be created and inventories, teams, projects and more can be assigned to individual organizations. Organization administrators can create additional objects in their respective organization.
After setting up the organization and organization administrators, the super admin user is not needed for daily operations and its password can be stored securely. The password could be split into 2 or more peaces, so no single person knows the whole password. Additionally a Privileged Access Management Tool could be used to hand out only time limited temporary passwords when needed.
Team) --> netdev(Network Device); top(Default Organization) --> dborg(Organization Database
Team) --> dbserver(Database Servers); top(Default Organization) --> sysorg(Organization Application
Team) --> appserver(Application Servers);
Pro
With this architecture one centralized Ansible Tower cluster can be used to manage all devices. This simplifies management and reduces efforts to manage the whole infrastructure. Since the different organizations are separate from each other, an administrator or attacker can not access inventories, credentials, jobs or other data from other organizations.
Con
Not having access to the default admin account might make it harder to do ad-hoc changes or troubleshooting. This can be mitigated by using Ansible to automate the configuration and management of the Ansible Tower cluster.
The actual Ansible Tower cluster is still a shared infrastructure for all sub organizations, therefor a limited security risk still exists. One could think of security flaws in the Ansible Tower code which might allow an intruder to get access to the other organizations.
Conclusion
All centralized management tools are a potential security risk allowing an attacker to gain control over all the managed systems. Ansible Tower provides best practices to harden the installation and to reduce this risk. Working with different organizations can add an additional layer of security - by restricting access to the super admin account the potential attack vector can be reduced further. Setting up dedicated Ansible Tower clusters provides the maximum level of security, but requires more effort when it comes to management and maintenance. Those concepts can also be combined allowing us to find the individual balance between convenience and security.