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.
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.
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
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:
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.
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 ..
copy/rsync your updates into the plugin directory and restart all processes.
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).