AWX and AAP — Job Templates, Credentials, Surveys and RBAC — Infrastructure as Code

AWX is the open-source upstream project for Red Hat's Ansible Automation Platform (AAP, formerly Ansible Tower). Both provide a web-based UI, REST API and CLI for running Ansible playbooks at scale — the enterprise equivalent of Terraform Cloud for Ansible. Where running ansible-playbook directly requires the operator to have Ansible installed, credentials configured, and the correct inventory available, AWX centralises all of this: playbooks are stored in Git repositories that AWX polls for updates, credentials are encrypted and stored in the AWX database, inventories are managed centrally with dynamic inventory plugin support, and job execution is logged, audited and visible to all authorised team members. AWX transforms Ansible from a per-engineer command-line tool into a shared organisational automation platform with governance, access control, and scheduling.

The four central concepts in AWX that engineers must understand are: Job Templates (a reusable configuration that combines a playbook, inventory, credentials and extra variables into a single executable unit), Credentials (encrypted storage for SSH keys, cloud provider credentials, vault passwords and source control tokens that are injected at runtime without being visible to users), Surveys (web forms that prompt operators for variable values before running a job — enabling parameterised deployments without requiring command-line access), and RBAC (role-based access control that grants teams different levels of access to specific resources — development teams can run jobs but not modify them, operations teams can create templates, administrators can manage all resources). These four concepts map directly to enterprise deployment governance requirements: defined change procedures (job templates), credential management (credentials), operator self-service (surveys), and access control (RBAC).

Analogy🏏Cricket

🏏 Think of it like cricket: Terraform Cloud is the ICC's centralised match management platform — instead of each national board (team) maintaining its own scoring system, umpire assignment software and results database (self-managed CI/CD + S3 backend), the ICC platform handles all of this centrally. When a board member proposes a rule change (pull request), the platform automatically simulates the match under the new rules (speculative plan on PR), shows the referees the impact (plan output in PR comment), and requires the match committee to approve (policy gates) before the rule takes effect. The audit log records every change, every approval, and who made each decision — providing the governance and traceability that serious tournament operations require.

bash

# AWX Job Template configuration (via AWX CLI / REST API)
# The following shows the logical configuration — actual AWX setup is via UI or API

# Job Template: Cricket API Deployment
awx job_templates create \
  --name 'Cricket API — Deploy' \
  --project 'cricket-infrastructure' \
  --playbook 'playbooks/deploy_cricket_api.yml' \
  --inventory 'Cricket Production' \
  --credential 'Cricket AWS Credentials' \
  --credential 'Cricket Vault Password' \
  --extra_vars '{"app_version": "latest"}' \
  --ask_variables_on_launch true \
  --verbosity 1

# Credential: SSH key for EC2 instances (encrypted at rest in AWX database)
awx credentials create \
  --name 'Cricket EC2 SSH Key' \
  --credential_type 'Machine' \
  --inputs '{"username": "ec2-user", "ssh_key_data": "@/path/to/key.pem"}'

# Credential: AWS access (via IAM role injection or access keys)
awx credentials create \
  --name 'Cricket AWS Credentials' \
  --credential_type 'Amazon Web Services' \
  --inputs '{"username": "access-key-id", "password": "secret-key"}'

# Survey: parameterise deployment without command-line access
awx job_templates modify 42 --survey_spec '{
  "name": "Cricket API Deployment Survey",
  "description": "Configure the deployment parameters",
  "spec": [
    {
      "variable": "app_version",
      "question_name": "Application Version",
      "question_description": "Git tag or branch to deploy (e.g. v2.1.0)",
      "required": true,
      "type": "text",
      "default": "main"
    },
    {
      "variable": "target_environment",
      "question_name": "Target Environment",
      "question_description": "Which environment to deploy to",
      "required": true,
      "type": "multiplechoice",
      "choices": "staging\nproduction",
      "default": "staging"
    },
    {
      "variable": "enable_maintenance_mode",
      "question_name": "Enable Maintenance Mode",
      "question_description": "Show maintenance page during deployment",
      "required": false,
      "type": "multiplechoice",
      "choices": "yes\nno",
      "default": "no"
    }
  ]
}'

bash

# AWX RBAC configuration
# Grant different access levels to different teams

# Development team: can view and launch jobs, cannot modify templates
awx teams create --name 'Cricket Dev Team' --organization 'Sri Hayavadhana'
awx role grant \
  --team 'Cricket Dev Team' \
  --type 'execute' \
  --resource_type job_template \
  --resource_name 'Cricket API — Deploy'

# Operations team: can create and modify job templates
awx role grant \
  --team 'Cricket Ops Team' \
  --type 'admin' \
  --resource_type project \
  --resource_name 'cricket-infrastructure'

# Security team: read-only access to audit job history
awx role grant \
  --team 'Cricket Security Team' \
  --type 'read' \
  --resource_type organization \
  --resource_name 'Sri Hayavadhana'

# AWX REST API: trigger a job programmatically (for CI integration)
curl -s -X POST \
  -H 'Content-Type: application/json' \
  -H 'Authorization: Bearer YOUR_AWX_TOKEN' \
  -d '{"extra_vars": {"app_version": "v2.1.0", "target_environment": "staging"}}' \
  https://awx.cricket-analytics.io/api/v2/job_templates/42/launch/ | \
  python3 -m json.tool | grep -E 'id|status|job'

# Monitor job status
JOB_ID=123
curl -s \
  -H 'Authorization: Bearer YOUR_AWX_TOKEN' \
  https://awx.cricket-analytics.io/api/v2/jobs/${JOB_ID}/ | \
  python3 -m json.tool | grep -E 'status|failed|started|finished'