This technical deep dive highlights key capabilities released as part of Twistlock 18.11. To learn more about what’s included with Twistlock 18.11, check out our full release blog post.

The latest release of Twistlock, Twistlock 18.11, supports more open standards for alerting with Prometheus and Webhooks. Twistlock is designed to integrate with the entire cloud native stack. Prometheus, the open-source monitoring system, has become one of the top open source monitoring tools for enterprises building modern cloud native applications. Let’s take a look at Prometheus and how our integration is being implemented.

How does the Prometheus integration work?

Prometheus is a monitoring platform that collects metrics from targets by scraping their published endpoints. Twistlock can be configured to be a Prometheus target. You can use Prometheus to monitor time series data across your environment and show high-level, dashboard-like, stats to visualize trends and changes. The Twistlock instrumentation lets you track metrics such as the total number of connected Defenders and the total number of container images in your environment being protected by Defender.

Metrics are a core Prometheus concept. Instrumented systems expose metrics. Prometheus stores the metrics in its time-series database, and makes them easily available to query to understand how systems behave over time.

Twistlock metrics cover a wide spectrum of data — here are a few examples:

  • totalDefenders: Total number of Defenders connected to Console.
  • images_high_vulnerabilities: Total number of containers impacted by high vulnerabilities. This can easily be changed to include data on Critical, Medium, or Low vulnerabilities for hosts, containers, or serverless functions.
  • app_firewall_events: Total number of app firewall (CNAF) events. Twistlock can also surface network firewall events (CNNF).
  • host_runtime_events: Total number of host runtime events. Twistlock can surface container runtime events, access events, API events, and Defender events.

The Prometheus server scrapes endpoints at configurable time intervals. Twistlock refreshes vulnerability and compliance data every 24 hours. All other data is refreshed every 10 minutes. Regardless of the value you set for the Prometheus scrape interval, new Twistlock data is only available at our refresh rates.

How to enable the integration

The following procedure shows you how to enable Twistlock’s Prometheus instrumentation and spin up a Prometheus server running in a container. If you already have a Prometheus server in your environment, all you need is the Twistlock scrape configuration.

Procedure

  1. Enable Twistlock’s Prometheus instrumentation.
    • Log into Twistlock Console.
    • Go to System > Logging.
    • Set Prometheus instrumentation to Enabled at the bottom of the window.

  2. Prepare a scrape configuration file for the Prometheus server.
    • Create a new file named prometheus.yml and open it for editing.
    • Enter the following configuration, where:
      • CONSOLE_ADDRESS is the DNS name or IP address for Twistlock Console.
      • USER is a Twistlock user, with the minimum role of Auditor.
      • PASS is the user’s password.



    Example prometheus.yml file:

    global:
      scrape_interval:     15s # Set the scrape interval to every 15 seconds. Default is every 1 minute.
      evaluation_interval: 15s # Evaluate rules every 15 seconds. The default is every 1 minute.
    
    # Twistlock scrape configuration.
    scrape_configs:
      - job_name: 'twistlock'
        static_configs:
        - targets: ['CONSOLE_ADDRESS:8081']
        metrics_path: /api/v1/metrics
        basic_auth:
          username: 'USER'
          password: 'PASS'

  3. Start the Prometheus server with the scrape configuration file.
    $ docker run \
      --rm \
      --network=host \
      -p 9090:9090 \
      -v /PATH_TO_YML/prometheus.yml:/etc/prometheus/prometheus.yml \
      prom/prometheus

  4. Validate that the Twistlock integration is properly set up. In a new browser window, go to http://<PROMETHEUS_HOST>:9090/targets.

    For testing, restart Console to get results immediately instead of waiting for the first 10 minute window to elapse.


  5. Create a graph that shows the number of deployed Defenders.
    Go to http://<PROMETHEUS_HOST>:9090/graph
    Click Add Graph.
    In the drop-down list, select twistlock_total_defenders.
    Click Execute. In the Console tab, you will see the value for total number of Defenders connected to Console.
    Open the Graph tab to see a visual representation of how the number of Defenders has changed over time, which you can see in the screenshot below:

  6. Create a graph that shows the number of containers with critical vulnerabilities .
    Go to http://<PROMETHEUS_HOST>:9090/graph
    Click Add Graph.
    In the drop-down list, select twistlock_containers_critical_vulnerabilities.
    Click Execute. In the Console tab, you will see the value for total number of Containers with Critical vulnerabilities.
    Open the Graph tab to see a visual representation of the number of Containers with critical vulnerabilities. (As you can see, my environment only has a single container with a Critical vulnerability).

  7. Create a graph that shows the number of hosts with high vulnerabilities.
    Go to http://<PROMETHEUS_HOST>:9090/graph
    Click Add Graph.
    In the drop-down list, select twistlock_hosts_high_vulnerabilities.
    Click Execute. In the Console tab, you will see the value for total number of Hosts with high vulnerabilities.
    Open the Graph tab to see a visual representation of the number of Hosts with high vulnerabilities. (As you can see all my hosts are patched with the latest packages and i got 0 hosts with high vulnerabilities).

With those three examples you can see how easy it is to start monitoring the whole environment including your containers and underlying hosts, or hosts without containers.

Summary

With the integration and support of Prometheus, Twistlock enables flexible ways to setup alerting for your environment while making it easy to integrate it into any existing monitoring and alerting systems you already have in place. The metrics provided can be used to for vulnerability, compliance, runtime, access and firewall monitoring for serverless, containers and VMs or physical machines with a Defender installed from a single place — this helps to simplify and unify your monitoring strategy while bringing together the traditional world of IT with the cloud native world. If you’d like more information on this topic or want a demo then get in touch!

← Back to All Posts Next Post →