Ansible Tower / AWX / Automation controller Security

Reading time: 12 minutes

tip

AWS हैकिंग सीखें और अभ्यास करें:HackTricks Training AWS Red Team Expert (ARTE)
GCP हैकिंग सीखें और अभ्यास करें: HackTricks Training GCP Red Team Expert (GRTE) Azure हैकिंग सीखें और अभ्यास करें: HackTricks Training Azure Red Team Expert (AzRTE)

HackTricks का समर्थन करें

Basic Information

Ansible Tower या इसका ओपन-सोर्स संस्करण AWX को Ansible का उपयोगकर्ता इंटरफ़ेस, डैशबोर्ड, और REST API के रूप में भी जाना जाता है। भूमिका-आधारित पहुँच नियंत्रण, नौकरी अनुसूची, और ग्राफिकल इन्वेंटरी प्रबंधन के साथ, आप एक आधुनिक UI से अपनी Ansible अवसंरचना का प्रबंधन कर सकते हैं। Tower का REST API और कमांड-लाइन इंटरफ़ेस इसे वर्तमान उपकरणों और कार्यप्रवाहों में एकीकृत करना सरल बनाते हैं।

Automation Controller Ansible Tower का एक नया संस्करण है जिसमें अधिक क्षमताएँ हैं।

Differences

इस के अनुसार, Ansible Tower और AWX के बीच मुख्य अंतर प्राप्त समर्थन और Ansible Tower की अतिरिक्त सुविधाएँ हैं जैसे भूमिका-आधारित पहुँच नियंत्रण, कस्टम APIs के लिए समर्थन, और उपयोगकर्ता-परिभाषित कार्यप्रवाह।

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: एक प्रोजेक्ट मूल रूप से एक Ansible प्लेबुक का संग्रह है जो एक संस्करण नियंत्रण प्रणाली (जैसे Git) से लिया गया है ताकि जब आवश्यक हो तो नवीनतम प्लेबुक को खींचा जा सके।
  • 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: एक उपयोगकर्ता AWX/Tower के साथ Web Interface या REST API के माध्यम से इंटरैक्ट कर सकता है। ये AWX/Tower द्वारा प्रदान की गई सभी कार्यक्षमताओं के लिए फ्रंट-एंड पहुँच प्रदान करते हैं।
  2. Job Initiation:
  • उपयोगकर्ता, वेब इंटरफ़ेस या API के माध्यम से, एक Job Template के आधार पर नौकरी शुरू करता है।
  • नौकरी टेम्पलेट में Inventory, Project (जिसमें प्लेबुक है), और Credentials के संदर्भ शामिल होते हैं।
  • नौकरी शुरू करने पर, AWX/Tower बैकएंड को निष्पादन के लिए नौकरी को कतार में लगाने के लिए एक अनुरोध भेजा जाता है।
  1. Job Queuing:
  • RabbitMQ वेब घटक और कार्य चलाने वालों के बीच संदेशों को संभालता है। एक बार जब नौकरी शुरू होती है, तो RabbitMQ का उपयोग करके कार्य इंजन को एक संदेश भेजा जाता है।
  • Redis कार्य कतार के लिए बैकएंड के रूप में कार्य करता है, निष्पादन की प्रतीक्षा कर रहे कतारबद्ध नौकरियों का प्रबंधन करता है।
  1. Job Execution:
  • Task Engine कतारबद्ध नौकरी को उठाता है। यह नौकरी से संबंधित प्लेबुक, इन्वेंटरी, और क्रेडेंशियल के बारे में आवश्यक जानकारी Database से प्राप्त करता है।
  • संबंधित Project से प्राप्त Ansible प्लेबुक का उपयोग करते हुए, कार्य इंजन निर्दिष्ट Inventory नोड्स के खिलाफ प्लेबुक चलाता है, प्रदान किए गए Credentials का उपयोग करते हुए।
  • जैसे-जैसे प्लेबुक चलती है, इसका निष्पादन आउटपुट (लॉग, तथ्य, आदि) कैप्चर किया जाता है और Database में संग्रहीत किया जाता है।
  1. Job Results:
  • एक बार जब प्लेबुक चलना समाप्त हो जाता है, तो परिणाम (सफलता, विफलता, लॉग) Database में सहेजे जाते हैं।
  • उपयोगकर्ता फिर वेब इंटरफ़ेस के माध्यम से परिणाम देख सकते हैं या उन्हें REST API के माध्यम से क्वेरी कर सकते हैं।
  • नौकरी के परिणामों के आधार पर, Notifications उपयोगकर्ताओं या बाहरी प्रणालियों को नौकरी की स्थिति के बारे में सूचित करने के लिए भेजी जा सकती हैं। सूचनाएँ ईमेल, Slack संदेश, वेबहुक, आदि हो सकती हैं।
  1. External Systems Integration:
  • Inventories को बाहरी प्रणालियों से गतिशील रूप से स्रोत किया जा सकता है, जिससे AWX/Tower AWS, Azure, VMware, और अधिक जैसे स्रोतों से होस्ट खींच सकता है।
  • Projects (प्लेबुक) को संस्करण नियंत्रण प्रणालियों से खींचा जा सकता है, यह सुनिश्चित करते हुए कि नौकरी निष्पादन के दौरान अद्यतन प्लेबुक का उपयोग किया जाए।
  • Schedulers and Callbacks का उपयोग अन्य प्रणालियों या उपकरणों के साथ एकीकृत करने के लिए किया जा सकता है, जिससे AWX/Tower बाहरी ट्रिगर्स पर प्रतिक्रिया कर सके या पूर्व निर्धारित समय पर नौकरियाँ चला सके।

AWX lab creation for testing

Following the docs यह संभव है कि docker-compose का उपयोग करके AWX चलाया जा सके:

bash
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

Supported roles

सबसे अधिक विशेषाधिकार प्राप्त भूमिका को System Administrator कहा जाता है। इस भूमिका के साथ कोई भी कुछ भी संशोधित कर सकता है।

एक white box security समीक्षा के लिए, आपको System Auditor role की आवश्यकता होगी, जो सभी सिस्टम डेटा को देखने की अनुमति देती है लेकिन कोई परिवर्तन नहीं कर सकती। एक और विकल्प Organization Auditor role प्राप्त करना होगा, लेकिन बेहतर होगा कि आप दूसरी भूमिका प्राप्त करें।

उपलब्ध भूमिकाओं का विस्तृत विवरण प्राप्त करने के लिए इसे विस्तारित करें
  1. System Administrator:
  • यह सुपरयूजर भूमिका है जिसमें सिस्टम में किसी भी संसाधन तक पहुंचने और उसे संशोधित करने की अनुमति है।
  • वे सभी संगठनों, टीमों, परियोजनाओं, इन्वेंटरी, नौकरी टेम्पलेट आदि का प्रबंधन कर सकते हैं।
  1. System Auditor:
  • इस भूमिका वाले उपयोगकर्ता सभी सिस्टम डेटा को देख सकते हैं लेकिन कोई परिवर्तन नहीं कर सकते।
  • यह भूमिका अनुपालन और निगरानी के लिए डिज़ाइन की गई है।
  1. Organization Roles:
  • Admin: संगठन के संसाधनों पर पूर्ण नियंत्रण।
  • Auditor: संगठन के संसाधनों तक केवल देखने की पहुंच।
  • Member: संगठन में बिना किसी विशेष अनुमति के बुनियादी सदस्यता।
  • Execute: संगठन के भीतर नौकरी टेम्पलेट चला सकते हैं।
  • Read: संगठन के संसाधनों को देख सकते हैं।
  1. Project Roles:
  • Admin: परियोजना का प्रबंधन और संशोधन कर सकते हैं।
  • Use: नौकरी टेम्पलेट में परियोजना का उपयोग कर सकते हैं।
  • Update: SCM (source control) का उपयोग करके परियोजना को अपडेट कर सकते हैं।
  1. Inventory Roles:
  • Admin: इन्वेंटरी का प्रबंधन और संशोधन कर सकते हैं।
  • Ad Hoc: इन्वेंटरी पर अद हॉक कमांड चला सकते हैं।
  • Update: इन्वेंटरी स्रोत को अपडेट कर सकते हैं।
  • Use: नौकरी टेम्पलेट में इन्वेंटरी का उपयोग कर सकते हैं।
  • Read: केवल देखने की पहुंच।
  1. Job Template Roles:
  • Admin: नौकरी टेम्पलेट का प्रबंधन और संशोधन कर सकते हैं।
  • Execute: नौकरी चला सकते हैं।
  • Read: केवल देखने की पहुंच।
  1. Credential Roles:
  • Admin: क्रेडेंशियल्स का प्रबंधन और संशोधन कर सकते हैं।
  • Use: नौकरी टेम्पलेट या अन्य संबंधित संसाधनों में क्रेडेंशियल्स का उपयोग कर सकते हैं।
  • Read: केवल देखने की पहुंच।
  1. Team Roles:
  • Member: टीम का हिस्सा लेकिन बिना किसी विशेष अनुमति के।
  • Admin: टीम के सदस्यों और संबंधित संसाधनों का प्रबंधन कर सकते हैं।
  1. Workflow Roles:
  • Admin: कार्यप्रवाह का प्रबंधन और संशोधन कर सकते हैं।
  • Execute: कार्यप्रवाह चला सकते हैं।
  • Read: केवल देखने की पहुंच।

Enumeration & Attack-Path Mapping with AnsibleHound

AnsibleHound एक ओपन-सोर्स BloodHound OpenGraph कलेक्टर है जो Go में लिखा गया है, जो एक read-only Ansible Tower/AWX/Automation Controller API टोकन को एक पूर्ण अनुमति ग्राफ में बदल देता है जिसे BloodHound (या BloodHound Enterprise) के अंदर विश्लेषण के लिए तैयार किया गया है।

यह क्यों उपयोगी है?

  1. Tower/AWX REST API अत्यंत समृद्ध है और हर ऑब्जेक्ट और RBAC संबंध को उजागर करता है जो आपकी इंस्टेंस जानती है।
  2. सबसे कम विशेषाधिकार (Read) टोकन के साथ भी सभी सुलभ संसाधनों (संगठन, इन्वेंटरी, होस्ट, क्रेडेंशियल्स, परियोजनाएं, नौकरी टेम्पलेट, उपयोगकर्ता, टीमें…) को पुनरावृत्त रूप से सूचीबद्ध करना संभव है।
  3. जब कच्चे डेटा को BloodHound स्कीमा में परिवर्तित किया जाता है, तो आपको वही attack-path दृश्यता क्षमताएं मिलती हैं जो Active Directory आकलनों में इतनी लोकप्रिय हैं - लेकिन अब आपके CI/CD संपत्ति पर निर्देशित हैं।

सुरक्षा टीमें (और हमलावर!) इसलिए:

  • जल्दी से समझ सकते हैं कौन क्या का एडमिन बन सकता है।
  • क्रेडेंशियल्स या होस्ट की पहचान करें जो एक अप्रिविलेज्ड खाते से पहुंच योग्य हैं।
  • पूर्ण नियंत्रण प्राप्त करने के लिए कई “Read ➜ Use ➜ Execute ➜ Admin” किनारों को जोड़ सकते हैं Tower इंस्टेंस या अंतर्निहित बुनियादी ढांचे पर।

Prerequisites

  • Ansible Tower / AWX / Automation Controller जो HTTPS के माध्यम से पहुंच योग्य है।
  • एक उपयोगकर्ता API टोकन जो केवल Read के लिए स्कोप किया गया है (जो User Details → Tokens → Create Token → scope = Read से बनाया गया है)।
  • कलेक्टर को संकलित करने के लिए Go ≥ 1.20 (या पूर्व-निर्मित बाइनरी का उपयोग करें)।

Building & Running

bash
# 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 Transformation

कच्चे Tower डेटा को फिर BloodHound OpenGraph में परिवर्तित किया जाता है, जिसमें AT (Ansible Tower) से पूर्ववर्ती कस्टम नोड्स होते हैं:

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

और संबंधों / विशेषाधिकारों को मॉडलिंग करने वाले किनारे:

  • ATContains, ATUses, ATExecute, ATRead, ATAdmin

परिणाम को सीधे BloodHound में आयात किया जा सकता है:

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

आप वैकल्पिक रूप से कस्टम आइकन अपलोड कर सकते हैं ताकि नए नोड प्रकार दृश्य रूप से भिन्न हों:

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

Defensive & Offensive Considerations

  • एक Read टोकन सामान्यतः हानिरहित माना जाता है लेकिन फिर भी पूर्ण टोपोलॉजी और हर क्रेडेंशियल मेटाडेटा लीक करता है। इसे संवेदनशील मानें!
  • कम से कम विशेषाधिकार लागू करें और अप्रयुक्त टोकनों को घुमाएँ / रद्द करें।
  • अत्यधिक अनुक्रमण (कई अनुक्रमिक GET अनुरोध, उच्च पृष्ठन गतिविधि) के लिए API की निगरानी करें।
  • हमलावर के दृष्टिकोण से, यह CI/CD पाइपलाइन के भीतर प्रारंभिक पैर जमाना → विशेषाधिकार वृद्धि तकनीक के लिए एकदम सही है।

References

tip

AWS हैकिंग सीखें और अभ्यास करें:HackTricks Training AWS Red Team Expert (ARTE)
GCP हैकिंग सीखें और अभ्यास करें: HackTricks Training GCP Red Team Expert (GRTE) Azure हैकिंग सीखें और अभ्यास करें: HackTricks Training Azure Red Team Expert (AzRTE)

HackTricks का समर्थन करें