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
1dev-box$ cp -r plugin_instance_type_blacklist plugins/2dev-box$ ls -alh plugins/3total 484drwxr-xr-x 9 username staff 306B Sep 12 07:57 .5drwxr-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
1volumes: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
1dev-box$ rm -rf plugins/plugin_instance_type_blacklist2dev-box$ ls -alh plugins/3total 484drwxr-xr-x 9 username staff 306B Sep 12 07:57 .5drwxr-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).
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).