This post was originally published here by ash wilson.
We’ve just released Cortex v1.1 (https://github.com/cloudpassage/cortex), and while some changes may seem subtle, they greatly improve the functionality and efficiency of Cortex, giving you an even more seamless experience.
Some of the changes you’ll see include:
File-based configuration for scheduled jobs:
In the original design, users could disable certain components in Cortex and re-implement them in with other automation systems. Now, we have refactored the scheduler and task dispatcher to make scheduled task dead simple to add. It’s as easy as copying a config file, adjusting the config file to meet your specific task’s requirements, and restarting the scheduler component. The schedule is defined in the config file, and the task’s code itself lives in a container image.
Though the ease of adding new functionality to Cortex itself was originally just a secondary goal, early feedback indicated that instead of using Cortex as a set of training wheels to jumpstart security automation, many of our users wanted to build additional integrations on top of Cortex.
We’ve also included a few tasks for getting events and scan results from the Halo platform to S3, in the Cortex repository. Adding a new scheduled task is as simple as creating a config file to describe the task and schedule, and then building a container image that contains the code that performs the task. This bears some similarity to serverless – or function-as-a-service – applications. Cortex’s scheduler, however, is cloud platform-independent.
For more detailed information on enabling scheduler tasks, take a look here: https://github.com/cloudpassage/cortex/tree/master#scheduler-configuration
Policies for monitoring scheduled tasks in Cortex:
Simply moving information from one place to another is only part of the challenge when automating the delivery of compliance information. If the task is interrupted or fails to complete, you need to be notified quickly so that you can take corrective action as soon as possible. To make this easy, we’ve included a Halo Log-based IDS (LIDS) policy within Cortex to track (and optionally alert on) task execution failures.
Instructions for setting up Cortex for this kind of monitoring using Halo are here: https://github.com/cloudpassage/cortex/tree/master#monitoring-cortexs-scheduled-tasks
Proxy support:
Cortex now supports deployment behind a web proxy. One environment variable, and the setting propagates to all components in the Cortex application.
For more information, see https://github.com/cloudpassage/cortex/tree/master#setup-and-use
Improved reliability:
Parts of Cortex depend on external services (like Slack). When Cortex is unable to maintain a connection with these other services, the Cortex component responsible for managing that communication automatically restarts. Since no application components in Cortex carry critical state, we simply restart the specific component that’s experiencing the issue.
Feedback from Cortex v1.0 users indicated that some components were restarting more frequently than we want them to. We have improved the logic in Cortex that maintains connections with those external services so that we can more gracefully handle sub-optimal operating conditions without immediately resorting to a component restart.
Photo:Tripwire
