Reacting to Red Hat Insights CVE advisories and enhanced malware detection with Event-Driven Ansible and ServiceNow

Event-driven automation is the new thing in automation that everyone wants to know about these days, and Red Hat has its own proposal: Event-Driven Ansible.

This post covers configuring Red Hat Insights as a source of events for Event-Driven Ansible and performing detection and automatic resolution of common vulnerabilities and exposures (CVEs) in your infrastructure.

What is event-driven automation? It is the process of responding automatically to changing conditions in an IT environment to help resolve issues faster and reduce routine, repetitive tasks.

OK, that's important, but what is Red Hat's perspective on a typical event-driven automation process?

Red Hat uses a receive, decide and respond model. Components receive an event from a source like a monitoring tool, use a rules-based design and decision engine to determine the appropriate action, then take that action automatically. 

Of course, the best tools must be flexible enough to respond across a complex multivendor environment, so I’ll show you how to integrate with Insights as a source of events. You could choose from many others, however.

So, what do you need to create event-driven automation artifacts using Ansible Automation Platform?

Event-Driven Ansible is all about flexibility, meaning you can codify the decisions you want made and design actions you want taken when certain conditions are met.

How does it work? There are three main components: sources, rules and actions. I'll discuss these in more detail.

Sources

Sources are the origin of event data you want to use. Think of Kafka and other vendor solutions that gather and aggregate event data. In this case, the source is Insights.

Rules

You create rules using Event-Driven Ansible. If you have ever written an Ansible Playbook, you are ready to start writing rules.

Ansible rules are similar to playbooks but think more about creating "If-this-then-that" scenarios. Instead of playbooks, these rules are in Ansible Rulebooks specific to event-driven automation. Ansible Rulebooks contain the event source and the instructions on what steps to perform when a certain condition is met–and the process is very flexible. In fact, you can even call your existing, trusted Ansible Playbooks as part of the actions to take in your rulebooks. Ansible job templates work similarly, too. 

Actions

Actions, such as resetting a network router, happen when Event-Driven Ansible finds that a condition or event is met and the Ansible Rulebook executes. It executes using your existing Ansible Automation Platform tooling.

Sources, rules and actions make up Event-Driven Ansible. You work with a flexible source to find events, write Ansible Rulebooks to define what to do when the event condition is met, and then Event-Driven Ansible takes action using your existing Ansible Automation Platform tooling.

In the following example, the rulebook instantiates one listener (Insights events) covering one use case (CVE detection and remediation).

Each listener reacts to events, trying to remediate an alert triggered by the application via playbooks that are part of the demo.

An Insights service generates each event, listening on port 5002 on localhost, which exposes the endpoints.

Configuring Insights to emit events

You can find a brief guide for configuring Insights to emit event notifications in this blog post. I will summarize the steps below, but please read Jerome's blog for further understanding.

Integrate Insights and Event-Driven Ansible

Integration on the Insights console side

You need to integrate Event-Driven Ansible with Insights. To do that, your Event-Driven Ansible machine (the one processing the events) must have an Internet connection and be reachable from the exterior. I don't have that in this case (I'm using a home lab machine behind a NAT router), so the solution is to use ngrok.

The best way to configure ngrok on your Event-Driven Ansible machine is as a service.

The most important thing to manage is the configuration file. Here is a basic example that works with this demo:

[root@eda ~]# cat ngrok.yml
# in ngrok.yml
authtoken: Abd2M6FgBt7k87204757BSEdMm3uGFGVdfd935V
log_level: info
log_format: term
log: stdout
region: eu
version: 2
tunnels:
 insights:
   proto: http
   addr: 5002

Next, log in to your Insights console and go to integrations:

Add the Insights EDA endpoint so that it can be used as an action in a behavior group notification in Settings > Notifications. Here is an example:

Integration on the Automation controller

Once your configuration is in place, generate a token that the Event-Driven Ansible controller will use to connect to the automation controller. To do so, go to the Users -> admin -> Token section in the controller and add a new token:

Integration on the Event-Driven Ansible machine

Save the token and open the Event-Driven Ansible controller URL. Go to the Users -> admin -> Token section and create a controller token:

Next, configure your project. In my case, my project files are in GitHub. For that, go to Resources -> Projects section and create a project:

You will also need to configure a rulebook activation as the listener. Go to the Views -> Rulebook Activations section and create a rulebook activation:

Once your objects are in place, go to the Views -> Rulebook Activations section and Your rulebook activation -> History to see the events:

The actual code

Keep in mind the structure of your code. It must follow a given set of folders; all the rules must be defined under the rulebooks directory, and the actions under the playbooks, as shown below:

Rulebook

The code in this example is simple. You need to specify the source of the events, its host and port, and also the token you will use to verify. Next, define the rules in the form of a condition and a job template to be executed when that condition is met. It looks like the following:

---
- name: EDA | Insights | Listen for events on a webhook
 hosts: localhost
 sources:
- redhatinsights.eda.insights:
    host: 0.0.0.0
    port: 5002
    token: redhatinsightstoken

 rules:
- name: EDA | Insights | Remediate Red Hat Insights Advisory with Ansible
  condition: event.payload is defined and event.payload.event_type == 'new-advisory'
  actions:
    - debug:
    - run_job_template:
        name: "[EDA] Insights Advisory playbook"
        organization: Demo Org
        job_args:
          extra_vars:
            insights_adv_type: "{{ event.payload.event_type }}"
            insights_adv_data: "{{ event.payload.events }}"
            insights_adv_host_data: "{{ event.payload.context }}"
            insights_adv_target_host: "{{ event.payload.context.display_name }}"

Actions

The playbook corresponding to the job template name specified in the rulebook defines the actions to be taken (or the playbook to be executed) when the event has been triggered.

In this case, the full code is quite lengthy, so I'll explain the first task and give you access to it.

---
- name: EDA | Insights | Show Advisory
 hosts: "{{ insights_adv_target_host }}"
 vars:
insights_api_url: "https://console.redhat.com/api"
insights_auth_user: "{{ rhsm_username }}"
insights_auth_password: "{{ rhsm_password  }}"

 tasks:    
- name: Create a list for each host with advisories
  ansible.builtin.set_fact:
    hosts_with_adv: "{{ hosts_with_adv | default([]) + [{ 'hostname' : insights_adv_host_data.display_name,
                                    'insights_id' : insights_adv_host_data.inventory_id,
                                    'advisory_id' : item.payload.advisory_id,
                                    'advisory_name' : item.payload.advisory_name,
                                    'advisory_type' : item.payload.advisory_type }] }}"
  loop: "{{ insights_adv_data }}"
[...]

As you can see, it is a simple processing of data. The key element is item.payload , as that is where Insights provides the information sent by the event.

Wrap up

Event-Driven Ansible combined with Red Hat Insights automates reacting to events for quick, consistent changes. It uses familiar Ansible tools and approaches to accomplish your specific goals. Use the ideas, techniques and files above to learn to use Event-Driven Ansible, then reap the benefits in your own organization.