Plugins Overview

Plugins are Python packages that are loaded when an InsightCloudSec process starts. These are primarily used for registering custom filters and packaging frontend assets to extend the user interface.

Expanded Plugin Documentation

InsightCloudSec supports extension via a comprehensive plugin system. Customers can add new content and workflows to support their unique requirements by writing their own extensions.

This capability requires access to our source code and is only available to customers. Reach out to us through the Customer Support Portal for access to both the repo and the additional documentation and instructions surrounding plugins.

Deprecated Content

Beginning with 22.4.7 (release date August 24, 2022) usage of DivvyDbObjects within plugins is deprecated. You will need to switch to DbObjects instead for any applicable configurations, as DivvyDbObjects will be removed in a future release.

Plugin Distribution and Loading

All workers, schedulers, web-servers and other InsightCloudSec-related processes pull plugins from a centralized database. The database is used as a central point for distributing plugins to other processes, similar to a file server. To avoid contention during plugin changes, ONLY the scheduler is allowed to update the plugin contents on the database. This includes new plugins, deleting plugins, and updating plugins.

Plugins can be discovered in two manners: either locally on the scheduler's file system or remotely to other sources such as HTTP or S3. It is for this reason that all plugin management should be done on the scheduler process space and not on workers and web-server processes. Plugins are currently only loaded on startup. If changes to plugins do occur or new plugins are added, then those processes will need to be restarted to pull in new changes.

Plugins are currently only loaded on startup. If changes to plugins do occur or new plugins are added, then those processes will need to be restarted to pull in new changes.

Loading and Unloading

To install, find a scheduler and simply copy the plugin directory to the plugins folder and it will be automatically be loaded into the software when the process starts.

bash
1
dev-box$ cp -r plugin_instance_type_blacklist plugins/
2
dev-box$ ls -alh plugins/
3
total 48
4
drwxr-xr-x 9 username staff 306B Sep 12 07:57 .
5
drwxr-xr-x 74 username staff 2.5K Sep 12 07:27 ..
6
-rw-r--r-- 1 username staff 2.0K Sep 12 07:57 plugin_instance_type_blacklist

For docker-compose deployments, the location of the plugins folder on your local filesystem is defined by mounting it as ./plugins inside the container. In our recommended docker-compose.yaml, this folder is named plugins and in the same directory as docker-compose.yaml, as defined by the volumes: directive here:

yaml
1
volumes:
2
- ./plugins:/plugins

To remove a plugin from the system you can either remove the file from the plugins folder or simply delete the directory permanently. The snippet below illustrates the removal of the example plugin from the example section.

bash
1
dev-box$ rm -rf plugins/plugin_instance_type_blacklist
2
dev-box$ ls -alh plugins/
3
total 48
4
drwxr-xr-x 9 username staff 306B Sep 12 07:57 .
5
drwxr-xr-x 74 username staff 2.5K Sep 12 07:27 ..

Updates

Simply copy/rsync your updates into the plugin directory and restart all processes.

Warnings (UI)

For users with configured Plugins, the landing page UI (available under the Setting (cog icon) --> Plugins) will now display warnings emitted during plugin loading.

Warnings appear as a yellow hazard icon on the list page (example shown below).

Plugins Landing Page - Example Warning

Individual plugins now provide a section containing the actual warnings on the "Manage Plugin" page, which is accessible for each plugin through the Admin options menu (shown below).

Plugins Landing Page - Access the Manage Plugin