Product Architecture
Overview of InsightCloudSec Product Architecture and Workflow
This page provides a high level overview of the InsightCloud product architecture and workflow. The diagram below summarizes the components required to deploy and run an InsightCloudSec platform installation.

InsightCloudSec Sample Product Workflow
Notes on Deployment
Since every environment is different, we recommend you reach out to us through Getting Support to connect. It will allow us to review the specifics of your requirements and any project goals you have to ensure that you get the information and recommendations that best meet your needs.
- Check out our FAQ for details on our available deployment methods, including self-hosted, managed self-hosted, and SaaS.
Note: The content on this page applies to self-hosted customers. For hosted/SaaS customers we recommend that you contact your CSM or the support team via the Customer Support Portal with any questions or concerns.
Deployment Options
InsightCloudSec is available to customers in the following deployment models:
- Self-Hosted: Deployed and managed by you in your environment
- Managed Self-Hosted: Deployed in your environment and managed by InsightCloudSec
- Software-as-a-Service (SaaS): Deployed and managed by InsightCloudSec in our environment
Check out the details, below.
InsightCloudSec Components
Value Names (DivvyCloud vs. InsightCloudSec)
Some URLs and back-end components use our former product name (DivvyCloud vs. InsightCloudSec). Updates to the naming of these components will be communicated when changes are made, but note that the name difference does not affect functionality within the product.
This section includes some basic details about InsightCloudSec platform components. This list is not exhaustive and may vary based on your deployment needs. For specifics reach out to us through Customer Support Portal.
Instances
InsightCloudSec runs on Ubuntu and CentOS variants. We recommend using Ubuntu 18.04+; CentOS 7+ may also be used.
Workers
Workers refer to a process that does something other than serve web requests. A “worker” may process a queue, run scheduled jobs using process files, or act on any number of other support-type activities. It generally does not interface with users.
Scheduler
In InsightCloudSec, the “scheduler” is responsible for delegating tasks to the Workers. It maintains a job queue in Redis and delegates tasks to the workers. Jobs fall into three categories: High (p0), Medium (p1), and Low (p2) priority.
- High priority jobs include any immediate on-demand jobs such as stopping or starting an instance, or a User enqueueing a harvest job.
- Medium priority jobs include recurring background jobs, such as calculating Insight compliance.
- Low priority jobs are regularly scheduled harvesting jobs.
Note: If you're using AWS CloudWatch or GCP Stackdriver, the InsightCloudSec job categories will display differently within CloudWatch/StackDriver:
- Immediate (p0)
- High Priority (p1)
- Standard (p2)
Interface Server
The web interface is how end users access the InsightCloudSec GUI. The Interface Server is generally accessible over port 8001, but this can be modified to a different value (e.g., "https://customername.insightcloudsec.com"
).
Backend Services
In addition to a frontend layer, InsightCloudSec has a backend that consists of MySQL 5.7.x and Redis 5.x. These services can be fulfilled by dedicated virtual machines or public, cloud-based services such as AWS RDS and ElastiCache.
Note: We recommend you verify the requirements that apply to your individual cloud provider, for example AWS requirements are specified here.
Redis upgrade required
For customers on versions of InsightCloudSec prior to 21.4.x (pre-DivvyCloud rebranding), upgrading to version 21.4.x (or higher) we recommend upgrading to Redis 5.x. Contact us through the Customer Support Portal with any questions or concerns.
Browsers
For the best experience, we recommend using the latest version of Google Chrome. While some other browsers may be used we only currently support Google Chrome.
Network Connections
The InsightCloudSec platform needs access to some public Internet services in order to function properly. All of these network connections are HTTPS traffic on outbound TCP port 443. The specific list of network connections varies based upon requirements, but commonly include:
Connection | Purpose |
---|---|
divvycentral.divvycloud.com | InsightCloudSec licensing server |
backoffice.divvycloud.com | InsightCloudSec Insight distribution |
license-prod-1-reports.s3.amazonaws.com | Usage metrics and reporting (optional) |
\*.amazonaws.com | Amazon Web Services API endpoints |
management.azure.com | Microsoft Azure API endpoints |
www.googleapis.com/* | Google Cloud Platform API endpoints |
*.aliyuncs.com | Alibaba Cloud API endpoints |
*.sentry.io | Sentry (optional error reporting) |
r7.my.salesforce.com | Salesforce support widget |
For end-user access, InsightCloudSec runs on port 8001 but can be mapped to port 80 or 443 using any number of proxy services including Apache2, Nginx, AWS ELB, or others.
Proxy Configuration
Many customers have network security requirements that prohibit all outbound traffic from VPCs. Customers have successfully implemented InsightCloudSec using proxy servers. The following describes a typical two-part approach: pre-install and post-install.
- Pre-install, you must set system environment variables.
- Post-install, you must set InsightCloudSec environment variables.
To update system environment variables:
For Ubuntu, log into each instance via SSH and append the following to /etc/environment
http_proxy="http://<PROXYSERVERIP:PORT>"
https_proxy="https://<PROXYSERVERIP:PORT>"
no_proxy="mysql,redis,169.254.169.254"
For CentOS, log into each instance via SSH and append the following to /etc/profile.d/proxy.sh
export http_proxy="http://<PROXYSERVERIP:PORT>"
export https_proxy="https://<PROXYSERVERIP:PORT>"
export no_proxy="mysql,redis,169.254.169.254"
You should replace PROXYSERVERIP
and PORT
values with the actual IP and port values of your proxy servers. If your proxy server requires a username and password, you can format the proxy server variable as follows:
http_proxy="http://<USERNAME:PASSWORD@PROXYSERVERIP:PORT>"
If you are installing a Test Drive deployment, then update your no_proxy
variable further by adding these local and loopback IPs:
no_proxy="mysql,redis,169.254.169.254,localhost,127.0.0.0,127.0.1.1"
After configuring the proxy, change to the user, divvy
, and verify the change:
sudo su - divvy
env | grep proxy
The proxy configuration variables should be displayed. If not, log out of the system and log back in so that the environment variables take effect.
Next, install InsightCloudSec using a Test Drive or Production Deployments
Post-install, after stopping InsightCloudSec, update InsightCloudSec environment variables, which are located in /divvycloud/prod.env
. You will need to uncomment and update the following lines in the prod.env
file on each instance:
# Uncomment and adjust the below values if behind a proxy. Please note that
# 169.254.169.254 are used for AWS Instance/STS AssumeRole.
#http_proxy=http://proxy.acmecorp.com
#https_proxy=http://proxy.acmecorp.com
#no_proxy=mysql,redis,169.254.169.254
As before, replace proxy.acmecorp.com
with the actual IP and port values of your proxy servers. And, as before, if you are following the Test Drive deployment, add these local and loopback IPs to your no_proxy
to have the following:
no_proxy=mysql,redis,169.254.169.254,localhost,127.0.0.0,127.0.1.1
Updated 2 months ago