Installing the Deepfactor portal requires a Kubernetes (k8s) 1.18 or later cluster.
If you do not have a K8s cluster, you can deploy Deepfactor using the OVA or AMI service providers documentation to bring up a K8s cluster:
- AWS - https://docs.aws.amazon.com/eks/latest/userguide/create-cluster.html
- Azure - https://docs.microsoft.com/en-us/azure/aks/kubernetes-walkthrough-portal
- GCP - https://cloud.google.com/kubernetes-engine/docs/how-to/creating-a-zonal-cluster#console
You will also need Helm3 and kubectl installed on your local machine from which you intend to install Deepfactor Portal:
You will also need kube-config for your K8s cluster installed on your local machine.
The table below can be used to estimate the K8s CPU and memory requirements, based on the expected number of applications being observed. As K8s clusters comprise a number of nodes, each with their own complement of CPU and memory resources, the table below reflects the total requirement, spread across all nodes where the Deepfactor portal is deployed.
|Portal Size||Number of active containers (applications)||Number of inactive containers (applications)||CPU Requirement||Memory Requirement|
- Number of active containers: The number of actively running containers that are sending telemetry to the Deepfactor portal
- Number of inactive containers: The number of containers that have run in the past, and have their telemetry being stored/analyzed in the Deepfactor portal
- CPU Requirement: Number of CPUs recommended by Deepfactor for this configuration. This amount refers to the total number of CPUs recommended across all K8s nodes where the Deepfactor portal is deployed, not a single node. For example, a recommendation of 11 CPUs can be satisfied with three nodes with 4 CPUs each, or 2 nodes with 8 CPUs each. All nodes used for the Deepfactor portal should have a minimum of 4 CPUs.
- Memory Requirement: Total amount of memory recommended across all nodes where the Deepfactor portal is deployed. All nodes used for the Deepfactor portal should have a minimum of 4GB available.
The table above reflects the steady-state requirements for the Deepfactor portal and does not include any additional resources required for DAST scans. For DAST scans, add 2 CPUs and 2GB ram for each concurrent scan being run.
For portal configurations requiring more than 640 active containers, contact Deepfactor.
An SSL certificate is used to encrypt the telemetry traffic being sent to the Deepfactor portal. By default, a self-signed certificate is used, but a customer-provided certificate can also be used. If you wish to use a customer-provided certificate, you should generate that certificate before portal deployment (using whatever process is in place to generate such certificates). This certificate should be issued for the FQDN you want to assign to the Deepfactor portal. For example, deepfactor.mycompany.com.
If you want to use a self-signed certificate, we provide helper scripts. You can use the following commands to generate a self-signed certificate for the domain name of your choice.
Run the script generate-cert.sh by providing the hostname you want to assign to your Deepfactor Portal:
chmod +x generate-cert.sh
sudo ./generate-cert.sh <deepfactor_portal_hostname>
Generate Kubernetes secrets using the following command:
Run prerequisite.sh to create the deepfactor namespace and k8s secrets required by Deepfactor portal.
chmod +x prerequisite.sh
./prerequisite.sh portalkeypath="./portal.key" \
portalkeypath, portalcrtpath, portalcakeypath, poatalcacrtpath and pempath are the paths for the respective cert files. If you used generate-cert.sh, these files will be present in the same directory where the script was run.
Network connections used by the Deepfactor portal
- TCP/443 - Telemetry data from observed applications
- TCP/13443 - DAST scan results
Outbound internet connections made by the Deepfactor portal:
Package dependency database updates:
Note: If the connections above are blocked after product installation, the Deepfactor portal will still function but will not receive updates to the package dependency database.
CVE database updates:
Note: If the connections above are blocked after product installation, the Deepfactor portal will still function but will not receive updates to the CVE vulnerability database.
Deepfactor License Management
To use the Deepfactor Portal, you will need an active Deepfactor On-Premise license.
Please find the details of the Deepfactor licensing cost below:
Please reach out to us by clicking the contact us button to obtain a license.
- Endpoints sending Deepfactor telemetry data must be able to route to the inbound connections and cannot use a proxy.
- A self-signed certificate is generated during the initialization of the Deepfactor portal and will require a resolvable FQDN name to the IP address of the Deepfactor portal.
- Link to supported applications & operating systems.