AnsibleByExample

Ansible splunk.es Module Example: Trigger Incident Response Playbook

Beginner
2024-01-013By Luca Berton

Lesson 1 of 15 in Foundations

Ansible Foundations to Production — full curriculum
  1. 1. Introduction to Ansible and Automation
  2. 2. Installing and Configuring Ansible
  3. 3. Running Ad-Hoc Commands
  4. 4. Writing Your First Playbook
  5. 5. Understanding and Using Modules
  6. 6. Variables and Facts
  7. 7. Conditionals and Loops
  8. 8. Handlers and Idempotency
  9. 9. Structuring Projects with Roles
  10. 10. Inventory Management
  11. 11. Using Ansible Vault for Secrets
  12. 12. Debugging and Troubleshooting
  13. 13. Real-World Automation Examples
  14. 14. Final Project: Deploy a Web Server
  15. 15. Bonus - What's Next with Ansible?
View path overview →

The splunk.es collection was announced at Red Hat Tech Day Netherlands 2026 (Bunnik, 3 June 2026) as one of twelve new content collections shipping for AAP 2.7. It targets Splunk Enterprise Security incident workflows and response plan automation, letting playbooks react to notable events instead of waiting on an analyst to click a button.

Example playbook

---
- name: Trigger incident response workflow from Splunk ES
  hosts: localhost
  gather_facts: false
  vars:
    splunk_es_host: "splunk-es.internal.example.com"
    splunk_es_port: 8089
    notable_event_id: "{{ es_notable_event_id }}"

  tasks:
    - name: Look up the notable event in Splunk ES
      splunk.es.notable_event_info:
        server_host: "{{ splunk_es_host }}"
        server_port: "{{ splunk_es_port }}"
        server_username: "{{ splunk_es_user }}"
        server_password: "{{ splunk_es_password }}"
        event_id: "{{ notable_event_id }}"
      register: notable_event

    - name: Escalate severity if source is a known critical asset
      splunk.es.notable_event:
        server_host: "{{ splunk_es_host }}"
        server_port: "{{ splunk_es_port }}"
        server_username: "{{ splunk_es_user }}"
        server_password: "{{ splunk_es_password }}"
        event_id: "{{ notable_event_id }}"
        urgency: critical
        status: in_progress
        owner: "soc-tier2"
      when: notable_event.result.asset_criticality == "high"

    - name: Trigger the incident response plan
      splunk.es.response_plan:
        server_host: "{{ splunk_es_host }}"
        server_port: "{{ splunk_es_port }}"
        server_username: "{{ splunk_es_user }}"
        server_password: "{{ splunk_es_password }}"
        event_id: "{{ notable_event_id }}"
        plan_name: "isolate-and-investigate"
        state: started
      register: response_plan

    - name: Show the response plan run ID
      ansible.builtin.debug:
        msg: "Response plan started: {{ response_plan.plan_run_id }}"

What it does and why

The playbook chains three splunk.es tasks against a notable event raised in Splunk Enterprise Security. First it pulls the event's details, then conditionally escalates urgency and reassigns ownership when the affected asset is flagged as high-criticality, and finally kicks off a named incident response plan (for example, an isolate-and-investigate workflow). In a real deployment this playbook is not run by hand — it's launched as a job template from AAP, invoked directly by Event-Driven Ansible when Splunk ES fires a notable event, or called from splunk.itsi correlation logic for closed-loop remediation.

Running IR steps this way keeps the analyst's console and the automation in sync: the ticket updates in Splunk ES at the same time infrastructure changes happen, so there's a single source of truth for what was done and when.

Notes / Gotchas

  • Store splunk_es_user and splunk_es_password in an AAP credential (or Vault, per the hashicorp.vault collection also announced at Red Hat Tech Day Netherlands 2026) — never in plaintext vars.
  • server_port: 8089 is Splunk's default management port, not the search head's web UI port (8000/443). Point at the wrong port and every task in this playbook fails at connection time.
  • Guard escalation and plan-trigger tasks with when conditions tied to real event fields (asset criticality, event status) so the playbook doesn't fire a costly response plan on every low-severity notable event.
  • splunk.es was newly announced for AAP 2.7 at the time of writing — pin the collection version in your requirements.yml and check the changelog before upgrading, since module arguments can still shift as the collection matures.
  • Pair this with splunk.enterprise for forwarder-side remediation (restarting or reconfiguring the Universal Forwarder) once the incident is contained.

Takeaway

splunk.es turns Splunk Enterprise Security notable events into first-class Ansible tasks, so incident response plans can be triggered, escalated, and tracked from the same automation platform that remediates the underlying systems.

References

All Tutorials