Ansible Tower / AWX / Automation controller Security

Basic Information

Ansible Tower 또는 그 오픈소스 버전 AWX는 Ansible의 사용자 인터페이스, 대시보드 및 REST API로도 알려져 있습니다. 역할 기반 접근 제어, 작업 예약 및 그래픽 인벤토리 관리를 통해 현대적인 UI에서 Ansible 인프라를 관리할 수 있습니다. Tower의 REST API 및 명령줄 인터페이스는 현재 도구 및 워크플로우에 통합하기 쉽게 만듭니다.

Automation Controller는 더 많은 기능을 갖춘 Ansible Tower의 최신 버전입니다.

Differences

이에 따르면, Ansible Tower와 AWX의 주요 차이점은 받은 지원이며, Ansible Tower는 역할 기반 접근 제어, 사용자 정의 API 지원 및 사용자 정의 워크플로우와 같은 추가 기능을 가지고 있습니다.

Tech Stack

• Web Interface: 사용자가 인벤토리, 자격 증명, 템플릿 및 작업을 관리할 수 있는 그래픽 인터페이스입니다. 직관적으로 설계되어 있으며 자동화 작업의 상태와 결과를 이해하는 데 도움이 되는 시각화를 제공합니다.

• REST API: 웹 인터페이스에서 할 수 있는 모든 작업을 REST API를 통해서도 수행할 수 있습니다. 이는 AWX/Tower를 다른 시스템과 통합하거나 일반적으로 인터페이스에서 수행하는 작업을 스크립트화할 수 있음을 의미합니다.

• Database: AWX/Tower는 구성, 작업 결과 및 기타 필요한 운영 데이터를 저장하기 위해 데이터베이스(일반적으로 PostgreSQL)를 사용합니다.

• RabbitMQ: AWX/Tower가 다양한 구성 요소 간에 통신하는 데 사용하는 메시징 시스템입니다. 특히 웹 서비스와 작업 실행기 간의 통신에 사용됩니다.

• Redis: Redis는 캐시 및 작업 큐의 백엔드 역할을 합니다.

Logical Components

• Inventories: 인벤토리는 작업(Ansible 플레이북)을 실행할 수 있는 호스트(또는 노드)의 모음입니다. AWX/Tower는 인벤토리를 정의하고 그룹화할 수 있으며, AWS, Azure 등과 같은 다른 시스템에서 호스트 목록을 가져오는 동적 인벤토리도 지원합니다.

• Projects: 프로젝트는 본질적으로 버전 관리 시스템(예: Git)에서 소스된 Ansible 플레이북의 모음으로, 필요할 때 최신 플레이북을 가져옵니다.

• Templates: 작업 템플릿은 특정 플레이북이 어떻게 실행될 것인지 정의하며, 인벤토리, 자격 증명 및 작업에 대한 기타 매개변수를 지정합니다.

• Credentials: AWX/Tower는 SSH 키, 비밀번호 및 API 토큰과 같은 비밀을 관리하고 저장하는 안전한 방법을 제공합니다. 이러한 자격 증명은 작업 템플릿과 연결되어 플레이북이 실행될 때 필요한 접근 권한을 가집니다.

• Task Engine: 마법이 일어나는 곳입니다. 작업 엔진은 Ansible을 기반으로 구축되어 있으며 플레이북을 실행하는 역할을 합니다. 작업은 작업 엔진에 배포되며, 지정된 인벤토리에 대해 지정된 자격 증명을 사용하여 Ansible 플레이북을 실행합니다.

• Schedulers and Callbacks: AWX/Tower의 고급 기능으로, 작업을 특정 시간에 실행하도록 예약하거나 외부 이벤트에 의해 트리거할 수 있습니다.

• Notifications: AWX/Tower는 작업의 성공 또는 실패에 따라 알림을 보낼 수 있습니다. 이메일, Slack 메시지, 웹훅 등 다양한 알림 수단을 지원합니다.

• Ansible Playbooks: Ansible 플레이북은 구성, 배포 및 오케스트레이션 도구입니다. 자동화되고 반복 가능한 방식으로 시스템의 원하는 상태를 설명합니다. YAML로 작성되며, 플레이북은 Ansible의 선언적 자동화 언어를 사용하여 구성, 작업 및 실행해야 할 단계를 설명합니다.

Job Execution Flow

1. User Interaction: 사용자는 웹 인터페이스 또는 REST API를 통해 AWX/Tower와 상호작용할 수 있습니다. 이러한 방법은 AWX/Tower가 제공하는 모든 기능에 대한 프론트엔드 접근을 제공합니다.

2. Job Initiation:

• 사용자가 웹 인터페이스 또는 API를 통해 작업 템플릿을 기반으로 작업을 시작합니다.

• 작업 템플릿에는 인벤토리, 프로젝트(플레이북 포함) 및 자격 증명에 대한 참조가 포함됩니다.

• 작업 시작 시, 실행을 위해 작업을 대기열에 추가하기 위해 AWX/Tower 백엔드에 요청이 전송됩니다.

1. Job Queuing:

• RabbitMQ는 웹 구성 요소와 작업 실행기 간의 메시징을 처리합니다. 작업이 시작되면 RabbitMQ를 사용하여 작업 엔진에 메시지가 전송됩니다.

• Redis는 실행 대기 중인 작업을 관리하는 작업 큐의 백엔드 역할을 합니다.

1. Job Execution:

• 작업 엔진이 대기열에 있는 작업을 가져옵니다. 작업과 관련된 플레이북, 인벤토리 및 자격 증명에 대한 필요한 정보를 데이터베이스에서 검색합니다.

• 관련 프로젝트에서 검색된 Ansible 플레이북을 사용하여 작업 엔진은 제공된 자격 증명을 사용하여 지정된 인벤토리 노드에 대해 플레이북을 실행합니다.

• 플레이북이 실행되는 동안 실행 출력(로그, 사실 등)이 캡처되어 데이터베이스에 저장됩니다.

1. Job Results:

• 플레이북 실행이 완료되면 결과(성공, 실패, 로그)가 데이터베이스에 저장됩니다.

• 사용자는 웹 인터페이스를 통해 결과를 확인하거나 REST API를 통해 쿼리할 수 있습니다.

• 작업 결과에 따라 알림이 전송되어 사용자 또는 외부 시스템에 작업 상태를 알릴 수 있습니다. 알림은 이메일, Slack 메시지, 웹훅 등이 될 수 있습니다.

1. External Systems Integration:

• 인벤토리는 외부 시스템에서 동적으로 소싱할 수 있어 AWX/Tower가 AWS, Azure, VMware 등과 같은 소스에서 호스트를 가져올 수 있습니다.

• 프로젝트(플레이북)는 버전 관리 시스템에서 가져올 수 있어 작업 실행 중 최신 플레이북을 사용할 수 있습니다.

• 스케줄러 및 콜백은 다른 시스템이나 도구와 통합하는 데 사용될 수 있어 AWX/Tower가 외부 트리거에 반응하거나 미리 정해진 시간에 작업을 실행할 수 있게 합니다.

AWX lab creation for testing

Following the docs 를 따르면 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

지원되는 역할

가장 권한이 높은 역할은 시스템 관리자입니다. 이 역할을 가진 사람은 모든 것을 수정할 수 있습니다.

화이트 박스 보안 검토를 위해서는 시스템 감사자 역할이 필요하며, 이 역할은 모든 시스템 데이터를 볼 수 있지만 변경할 수는 없습니다. 다른 옵션은 조직 감사자 역할을 얻는 것이지만, 다른 역할을 얻는 것이 더 좋습니다.