Ansible Tower / AWX / Automation controller Security

htARTE (HackTricks AWS Red Team Expert)를 통해 **제로**부터 **히어로**까지 AWS 해킹을 배우세요!

HackTricks를 지원하는 다른 방법:

• 회사가 HackTricks를 광고하길 원하거나 PDF 형식으로 HackTricks를 다운로드하려면 구독 요금제를 확인하세요!

• 공식 PEASS & HackTricks 스왜그를 구매하세요

• The PEASS Family를 발견하세요, 당사의 독점 NFTs 컬렉션

• 💬 Discord 그룹 또는 텔레그램 그룹에 가입하거나 트위터 🐦 @hacktricks_live를 팔로우하세요.

• HackTricks 및 HackTricks Cloud github 저장소로 PR을 제출하여 해킹 요령을 공유하세요.

기본 정보

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

자동화 컨트롤러는 더 많은 기능을 갖춘 Ansible Tower의 최신 버전입니다.

차이점

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

기술 스택

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

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

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

• RabbitMQ: 이는 AWX/Tower가 웹 서비스와 작업 실행기 간에 통신하는 데 사용하는 메시징 시스템입니다.

• Redis: Redis는 캐시 및 작업 대기열의 백엔드로 사용됩니다.

논리적 구성 요소

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

• 프로젝트: 프로젝트는 필요할 때 최신 플레이북을 가져오기 위해 버전 관리 시스템(예: Git)에서 가져온 Ansible 플레이북의 모음입니다.

• 템플릿: 작업 템플릿은 특정 플레이북이 실행되는 방식을 정의하며 작업에 필요한 인벤토리, 자격 증명 및 기타 매개변수를 지정합니다.

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

• 작업 엔진: 이곳에서 마법이 일어납니다. 작업 엔진은 Ansible을 기반으로 작성되었으며 플레이북을 실행하는 역할을 합니다. 작업은 작업 엔진에 전달되고, 그런 다음 지정된 인벤토리에 대해 지정된 자격 증명을 사용하여 Ansible 플레이북을 실행합니다.

• 스케줄러 및 콜백: 이는 AWX/Tower의 고급 기능으로 특정 시간에 실행되도록 예약된 작업이나 외부 이벤트에 의해 트리거된 작업을 허용합니다.

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

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

작업 실행 흐름

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

2. 작업 시작:

   • 사용자는 작업 템플릿을 기반으로 작업을 시작합니다.

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

   • 작업 시작 시 AWX/Tower 백엔드로 작업을 실행 대기열에 넣기 위한 요청이 전송됩니다.

3. 작업 대기열:

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

   • Redis는 작업 대기열의 백엔드로 작업을 실행 대기 중인 대기열을 관리합니다.

4. 작업 실행:

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

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

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

5. 작업 결과:

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

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

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

6. 외부 시스템 통합:

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

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

   • 스케줄러 및 콜백을 사용하여 다른 시스템이나 도구와 통합할 수 있어서 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)**입니다. 이 역할을 가진 사용자는 모든 것을 수정할 수 있습니다.

화이트박스 보안(White box security) 리뷰에서는 시스템 감사자(System Auditor) 역할이 필요하며, 이는 시스템 데이터를 모두 볼 수 있지만 변경할 수 없습니다. 다른 옵션으로 조직 감사자(Organization Auditor) 역할을 얻을 수도 있지만, 다른 역할을 얻는 것이 좋습니다.

자세한 역할 설명을 보려면 확장하세요

1. 시스템 관리자(System Administrator):

• 시스템의 모든 리소스에 액세스하고 수정할 수 있는 수퍼유저 역할입니다.

• 모든 조직, 팀, 프로젝트, 인벤토리, 작업 템플릿 등을 관리할 수 있습니다.

2. 시스템 감사자(System Auditor):

• 이 역할을 가진 사용자는 시스템 데이터를 모두 볼 수 있지만 변경할 수 없습니다.

• 이 역할은 규정 준수와 감시를 위해 설계되었습니다.

3. 조직 역할(Organization Roles):

• 관리자(Admin): 조직의 리소스에 대한 완전한 제어 권한.

• 감사자(Auditor): 조직의 리소스에 대한 읽기 전용 액세스.

• 구성원(Member): 특정 권한 없이 조직의 기본 멤버십.

• 실행(Execute): 조직 내에서 작업 템플릿을 실행할 수 있습니다.

• 읽기(Read): 조직의 리소스를 볼 수 있습니다.

4. 프로젝트 역할(Project Roles):

• 관리자(Admin): 프로젝트를 관리하고 수정할 수 있습니다.

• 사용(Use): 작업 템플릿에서 프로젝트를 사용할 수 있습니다.

• 업데이트(Update): 소스 컨트롤을 사용하여 프로젝트를 업데이트할 수 있습니다.

5. 인벤토리 역할(Inventory Roles):

• 관리자(Admin): 인벤토리를 관리하고 수정할 수 있습니다.

• Ad Hoc: 인벤토리에서 즉석 명령을 실행할 수 있습니다.

• 업데이트(Update): 인벤토리 소스를 업데이트할 수 있습니다.

• 사용(Use): 작업 템플릿에서 인벤토리를 사용할 수 있습니다.

• 읽기(Read): 읽기 전용 액세스.

6. 작업 템플릿 역할(Job Template Roles):

• 관리자(Admin): 작업 템플릿을 관리하고 수정할 수 있습니다.

• 실행(Execute): 작업을 실행할 수 있습니다.

• 읽기(Read): 읽기 전용 액세스.

7. 자격 증명 역할(Credential Roles):

• 관리자(Admin): 자격 증명을 관리하고 수정할 수 있습니다.

• 사용(Use): 작업 템플릿이나 기타 관련 리소스에서 자격 증명을 사용할 수 있습니다.

• 읽기(Read): 읽기 전용 액세스.

8. 팀 역할(Team Roles):

• 구성원(Member): 팀의 일원이지만 특정 권한이 없습니다.

• 관리자(Admin): 팀의 구성원 및 관련 리소스를 관리할 수 있습니다.

9. 워크플로우 역할(Workflow Roles):

• 관리자(Admin): 워크플로우를 관리하고 수정할 수 있습니다.

• 실행(Execute): 워크플로우를 실행할 수 있습니다.

• 읽기(Read): 읽기 전용 액세스.