Deepfactor Portal Architecture

Deepfactor on premise portal runs on a standard Kubernetes cluster. We provide various ways of deploying the portal on your infrastructure. The various options include

1. OVA for deployment on VMWare ESXi
2. AMI with CFT for deployment on AWS EC2
3. Helm charts for deployment into your K8s cluster on EKS, AKS, GKE, Rancher, etc

In the following sections, we outline the portal architecture and the various components it is composed of. In the later sections of the document, we also describe how you can customize the deployment for your needs.

We use standard K8s constructs such as deployments, services, jobs, and persistent volumes. The list of these are mentioned below.

Kubernetes Deployments #

1. Auth Service: Responsible for the authentication and SSO integrations.
2. Alert Service: Responsible for generating alerts from the telemetry received from your components
3. API Service: Acts as a REST api frontend for UI and other api clients.
4. Event Service: Receives events from your running applications and stores them in an OLAP DB.
5. CVE Service: Pulls and stores CVE information for various OS packages from different trusted sources.
6. Depcheck Service: This service checks all the dependencies your application has included against a collated DB of vulnerabilities and generates alerts.
7. Webscan Service: This service creates and manages K8s pods and jobs for running web/api scans
8. Proxy Service: This service sets up a reverse proxy with the Deepfactor runtime in your component to allow DAST scans without making your components ports public.
9. UI: This is the web frontend console that you interact with.
10. Ingress Controller: Manages external access to services in the Deepfactor Portal
11. Status Service: Queries the status of the various pods and services in the Deepfactor portal cluster
12. Notification Service: handles sending notifications to slack and other integrations

StatefulSets #

1. Postgres – PostgreSQL database which is used to store the information about users, applications, alert policies, etc
2. Clickhouse – Clickhouse database which is used to store events received from your components
3. Symbol Service – Stores the debug symbol files uploaded by you for C/C++ components.
4. ArchiveStore – Stores the report and logs of Web and api scans.

Note: We have equivalent Kubernetes services for all the deployments and statefulsets mentioned above.

Jobs #

1. dfstartup – Responsible for creating the Admin user and registering the portal with Deepfactor cloud.
2. DAST scan – this job is created on demand whenever the user starts a web / api scan. We set a memory minimum and maximum limit of 8Gi and 16Gi respectively.

ConfigMaps #

1. AppSettings – stores config parameters used by all of the services
2. Clickhouse – stores config parameters required for Clickhouse DB
3. Postgres – stores config parameters required for PostgreSQL DB
4. CVE – stores config parameters required by CVE Service
5. Dfstartup – stores information to setup the Admin User of Portal, required by DfStartup Job
6. Nginx – stores nginx config parameters
7. Ingress TCP – stores information to forward the TCP traffic of portal

In addition to the above, for our OVA and AMI deployments, we deploy the following additional K8s deployments to provide a simplified experience to our users.

1. Updater Service – Responsible for handling upgrades of the Deepfactor portal
2. Hostpath Provisioner – Responsible for provisioning the volumes for StatefulSets.