Purpose
This guide explains how to configure the Ansible Tower (AWX / Red Hat Ansible Automation Platform controller) Response integration in Logsign USO, so that Incidents and Alarms can automatically, or an analyst can manually, launch and manage Ansible job templates and ad hoc commands directly from a Logsign Incident. This lets Logsign trigger arbitrary Ansible automation (remediation playbooks, configuration changes, and so on) as a containment or recovery action, with the actual behavior entirely defined by whatever job templates and playbooks you have set up in Ansible Tower.
Prerequisites
- An Ansible Tower (or AWX / Ansible Automation Platform controller) instance with its API reachable from the Logsign server.
- An OAuth2 application (Client ID/Client Secret) or equivalent credential, plus a Tower account with permission to launch the job templates/ad hoc commands you intend to use.
- Use least privilege. Scope the Tower account to only the specific job templates, inventories, and credentials this integration should be able to trigger, rather than a full organization administrator account. Since this integration can execute arbitrary Ansible automation, treat it with the same care as any other system with execution rights on your infrastructure.
Step 1: Prepare Ansible Tower for API Access
- Log in to Ansible Tower with an administrator account.
- Create an OAuth2 application (Users > your account > Tokens, or Applications, depending on your Tower version) and note the Client ID and Client Secret.
- Create (or designate) a dedicated Tower user for Logsign to use, scoped to the specific job templates/inventories/credentials it should be able to trigger, and note its username/password.
Step 2: Configure the Integration in Logsign USO
In Logsign USO, go to Settings > Integrations > Responses, search for Ansible Tower, click Configure then +Device, and fill in:
| Field | Required | Description |
|---|---|---|
| Device Name | Yes | Free-text label identifying this Ansible Tower device in Logsign. |
| Host | Yes | Hostname of your Ansible Tower instance. |
| Username | Yes | The Tower account username from Step 1. |
| Password | Yes | Password for that account. Stored encrypted at rest. |
| Client Id | Yes | The OAuth2 Client ID from Step 1. |
| Client Secret | Yes | The OAuth2 Client Secret from Step 1. Stored encrypted at rest. |
| Insecure Skip Verify | Yes | Disables TLS certificate validation on Logsign's outbound calls when enabled. Defaults to on in this form; turn it off unless you have a specific reason to keep TLS validation disabled. |
Click Create to save the device.
Available Methods
Discovery (read scope)
- list_organizations, list_inventories (optional organizationId filter), list_credentials — list Tower resources, used to look up the IDs needed by the launch methods below.
Job templates
- job_launch (Containment/Recovery, depending on what the template does) — launches a job template. Args: jobTemplateId, inventory, credential, jobTags, extraVars.
- job_relaunch — relaunches a job. Args: hosts, credentials, jobId.
- job_cancel — cancels a running job. Arg: jobId.
- job_status / job_output — fetch a job's status or output/log. Arg: jobId.
- job_events_list — lists job events, with pagination/search.
Ad hoc commands
- create_adhoc_command (Containment) — runs an ad hoc Ansible command (not a saved job template). Args required: jobType, moduleName, verbosity; optional: inventory, limit, credential, moduleArgs, forks, extraVars, become_enabled, diff_mode.
- relaunch_adhoc_command / cancel_adhoc_command — relaunch or cancel an ad hoc command. Arg: commandId.
- adhoc_command_status / adhoc_command_output — fetch status or output of an ad hoc command. Arg: commandId.
Troubleshooting
| Symptom | Likely cause | What to check |
|---|---|---|
| 401 Unauthorized | Wrong Username/Password or Client Id/Client Secret. | Re-enter all four credential fields and confirm the OAuth2 application and Tower account are both still active. |
| 403 Forbidden on job_launch/create_adhoc_command | The Tower account does not have execute permission on the target job template, inventory, or credential. | Confirm the account's role/team assignment in Tower grants execute access to the specific resources being called. |
| job_launch succeeds but the job fails inside Ansible | A problem in the playbook/job template itself, unrelated to Logsign. | Use job_output to inspect the actual Ansible run log and diagnose the playbook-level failure. |
Notes and Limits
- This integration can trigger arbitrary Ansible automation. The actual effect of job_launch/create_adhoc_command depends entirely on what the referenced job template or ad hoc command does; review and restrict which job templates the scoped Tower account can access before wiring this into automated correlation rules.
- Use list_organizations/list_inventories/list_credentials to confirm valid ID values before calling job_launch.