Ansible Tower / AWX / Automation controller Security

Tip

学习并练习 AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
学习并练习 GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
学习并练习 Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

支持 HackTricks

• 查看 subscription plans!
• 加入 💬 Discord group 或者 telegram group 或 关注 我们的 Twitter 🐦 @hacktricks_live.
• 通过向 HackTricks 和 HackTricks Cloud github 仓库 提交 PRs 来分享 hacking tricks。

基本信息

Ansible Tower 或其开源版本 AWX 也被称为 Ansible 的用户界面、仪表板和 REST API。通过 基于角色的访问控制、作业调度和图形化库存管理，您可以通过现代用户界面管理您的 Ansible 基础设施。Tower 的 REST API 和命令行界面使其易于集成到当前工具和工作流程中。

Automation Controller 是 Ansible Tower 的一个更新版本，具有更多功能。

差异

根据 这篇文章，Ansible Tower 和 AWX 之间的主要区别在于获得的支持，Ansible Tower 具有额外的功能，如基于角色的访问控制、对自定义 API 的支持和用户定义的工作流。

技术栈

• Web 界面：这是用户可以管理库存、凭据、模板和作业的图形界面。它旨在直观，并提供可视化以帮助理解自动化作业的状态和结果。
• REST API：您可以在 Web 界面中执行的所有操作，也可以通过 REST API 执行。这意味着您可以将 AWX/Tower 与其他系统集成或编写通常在界面中执行的操作脚本。
• 数据库：AWX/Tower 使用数据库（通常是 PostgreSQL）来存储其配置、作业结果和其他必要的操作数据。
• RabbitMQ：这是 AWX/Tower 用于在不同组件之间通信的消息系统，特别是在 Web 服务和任务运行器之间。
• Redis：Redis 作为缓存和任务队列的后端。

逻辑组件

• 库存：库存是一个 主机（或节点）的集合，可以对其 运行作业（Ansible playbooks）。AWX/Tower 允许您定义和分组库存，并支持动态库存，可以 从其他系统获取主机列表，如 AWS、Azure 等。
• 项目：项目本质上是一个 Ansible playbooks 的集合，来源于 版本控制系统（如 Git），以便在需要时提取最新的 playbooks。
• 模板：作业模板定义 特定 playbook 的运行方式，指定 库存、凭据 和其他 参数。
• 凭据：AWX/Tower 提供了一种安全的方式来 管理和存储秘密，如 SSH 密钥、密码和 API 令牌。这些凭据可以与作业模板关联，以便在运行时为 playbooks 提供必要的访问权限。
• 任务引擎：这是魔法发生的地方。任务引擎基于 Ansible 构建，负责 运行 playbooks。作业被分派到任务引擎，然后使用指定的凭据在指定的库存上运行 Ansible playbooks。
• 调度程序和回调：这些是 AWX/Tower 中的高级功能，允许 作业在特定时间调度运行或由外部事件触发。
• 通知：AWX/Tower 可以根据作业的成功或失败发送通知。它支持多种通知方式，如电子邮件、Slack 消息、webhooks 等。
• Ansible Playbooks：Ansible playbooks 是配置、部署和编排工具。它们以自动化、可重复的方式描述系统的期望状态。使用 YAML 编写，playbooks 使用 Ansible 的声明性自动化语言来描述需要执行的配置、任务和步骤。

作业执行流程

1. 用户交互：用户可以通过 Web 界面 或 REST API 与 AWX/Tower 交互。这些提供了对 AWX/Tower 所有功能的前端访问。
2. 作业启动：
   • 用户通过 Web 界面或 API，根据 作业模板 启动作业。
   • 作业模板包括对 库存、项目（包含 playbook）和 凭据 的引用。
   • 在作业启动时，向 AWX/Tower 后端发送请求以将作业排队执行。
3. 作业排队：
   • RabbitMQ 处理 Web 组件与任务运行器之间的消息传递。一旦作业启动，消息将通过 RabbitMQ 发送到任务引擎。
   • Redis 作为任务队列的后端，管理等待执行的排队作业。
4. 作业执行：
   • 任务引擎 拾取排队的作业。它从 数据库 中检索与作业相关的 playbook、库存和凭据的必要信息。
   • 使用从相关 项目 中检索的 Ansible playbook，任务引擎在指定的 库存 节点上使用提供的 凭据 运行 playbook。
   • 当 playbook 运行时，其执行输出（日志、事实等）被捕获并存储在 数据库 中。
5. 作业结果：
   • 一旦 playbook 运行完成，结果（成功、失败、日志）将保存到 数据库 中。
   • 用户可以通过 Web 界面查看结果或通过 REST API 查询结果。
   • 根据作业结果，可以发送 通知 以告知用户或外部系统作业的状态。通知可以是电子邮件、Slack 消息、webhooks 等。
6. 外部系统集成：
   • 库存 可以从外部系统动态获取，允许 AWX/Tower 从 AWS、Azure、VMware 等来源提取主机。
   • 项目（playbooks）可以从版本控制系统中获取，确保在作业执行期间使用最新的 playbooks。
   • 调度程序和回调 可用于与其他系统或工具集成，使 AWX/Tower 对外部触发器做出反应或在预定时间运行作业。

AWX 实验室创建以进行测试

按照文档 可以使用 docker-compose 运行 AWX：

git clone -b x.y.z https://github.com/ansible/awx.git # Get in x.y.z the latest release version

cd awx

# Build
make docker-compose-build

# Run
make docker-compose

# Or to create a more complex env
MAIN_NODE_TYPE=control EXECUTION_NODE_COUNT=2 COMPOSE_TAG=devel make docker-compose

# Clean and build the UI
docker exec tools_awx_1 make clean-ui ui-devel

# Once migrations are completed and the UI is built, you can begin using AWX. The UI can be reached in your browser at https://localhost:8043/#/home, and the API can be found at https://localhost:8043/api/v2.

# Create an admin user
docker exec -ti tools_awx_1 awx-manage createsuperuser

# Load demo data
docker exec tools_awx_1 awx-manage create_preload_data

RBAC

支持的角色

最特权的角色称为 System Administrator。拥有此角色的任何人都可以 修改任何内容。

从 白盒安全 审查的角度来看，您需要 System Auditor role，该角色允许 查看所有系统数据 但不能进行任何更改。另一个选择是获取 Organization Auditor role，但获取前者会更好。

使用 AnsibleHound 进行枚举和攻击路径映射

AnsibleHound 是一个开源的 BloodHound OpenGraph 收集器，使用 Go 编写，将 只读 Ansible Tower/AWX/Automation Controller API 令牌转换为完整的权限图，准备在 BloodHound（或 BloodHound Enterprise）中进行分析。

这有什么用？

1. Tower/AWX REST API 非常丰富，暴露了您的实例所知道的 每个对象和 RBAC 关系。
2. 即使使用最低权限（Read）令牌，也可以递归枚举所有可访问的资源（组织、库存、主机、凭据、项目、作业模板、用户、团队……）。
3. 当原始数据转换为 BloodHound 架构时，您将获得与 Active Directory 评估中非常流行的 攻击路径 可视化能力相同的功能——但现在针对您的 CI/CD 资产。

因此，安全团队（和攻击者！）可以：

• 快速了解 谁可以成为什么的管理员。
• 识别 可以从无特权帐户访问的凭据或主机。
• 链接多个 “Read ➜ Use ➜ Execute ➜ Admin” 边缘，以获得对 Tower 实例或基础设施的完全控制。

先决条件

• 可通过 HTTPS 访问的 Ansible Tower / AWX / Automation Controller。
• 仅限 Read 的用户 API 令牌（从 User Details → Tokens → Create Token → scope = Read 创建）。
• Go ≥ 1.20 用于编译收集器（或使用预构建的二进制文件）。

构建和运行

# Compile the collector
cd collector
go build . -o build/ansiblehound

# Execute against the target instance
./build/ansiblehound -u "https://tower.example.com/" -t "READ_ONLY_TOKEN"

内部的 AnsibleHound 执行 分页 GET 请求，针对（至少）以下端点，并自动跟随每个 JSON 对象中返回的 related 链接：

/api/v2/organizations/
/api/v2/inventories/
/api/v2/hosts/
/api/v2/job_templates/
/api/v2/projects/
/api/v2/credentials/
/api/v2/users/
/api/v2/teams/

所有收集的页面都合并到一个单一的 JSON 文件中（默认：ansiblehound-output.json）。

BloodHound 转换

原始 Tower 数据随后被 转换为 BloodHound OpenGraph，使用以 AT（Ansible Tower）为前缀的自定义节点：

• ATOrganization, ATInventory, ATHost, ATJobTemplate, ATProject, ATCredential, ATUser, ATTeam

以及建模关系/权限的边：

• ATContains, ATUses, ATExecute, ATRead, ATAdmin

结果可以直接导入到 BloodHound：

neo4j stop   # if BloodHound CE is running locally
bloodhound-import ansiblehound-output.json

您可以选择上传 自定义图标，以便新节点类型在视觉上有所区别：

python3 scripts/import-icons.py "https://bloodhound.example.com" "BH_JWT_TOKEN"

防御与攻击考虑

• 读取 令牌通常被认为是无害的，但仍然泄露 完整拓扑和每个凭证元数据。将其视为敏感信息！
• 强制 最小权限 并轮换/撤销未使用的令牌。
• 监控 API 以防止过度枚举（多个连续的 GET 请求，高分页活动）。
• 从攻击者的角度来看，这是一种完美的 初始立足点 → 权限提升 技术，适用于 CI/CD 管道。

参考

• AnsibleHound – Ansible Tower/AWX 的 BloodHound 收集器
• BloodHound OSS

Tip

学习并练习 AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
学习并练习 GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
学习并练习 Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

支持 HackTricks

• 查看 subscription plans!
• 加入 💬 Discord group 或者 telegram group 或 关注 我们的 Twitter 🐦 @hacktricks_live.
• 通过向 HackTricks 和 HackTricks Cloud github 仓库 提交 PRs 来分享 hacking tricks。