Software Requirements #
Installing the Deepfactor portal requires a Kubernetes (k8s) version 1.23 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.
#
Hardware Requirements #
You can install the Deepfactor in different deployment environments depending upon your infrastructure and number of applications you want to observe. If you want to observe less than 150 applications (containers) with Deepfactor, we recommend using the OVA or AMI portal as it can run in a single node and is easier to maintain.
If you would like to observe more than 150 applications (containers) with Deepfactor, you can use our helm charts to install Deepfactor portal in your K8s clusters. We add default CPU and memory limits on all of our pods and based on these values, you will need to provision 20 vCPU for Deepfactor portal services. For example on AWS, you can use five nodes of m5.xlarge (4 vCPU, 16GB RAM). However, you can change the pod limits based on the number of concurrent containers you want to observe with Deepfactor. The following articles describes how to customize Deepfactor portal pod limits
Deploy Deepfactor Portal With Resource Limits
The table below provides estimates of CPU and memory usage by Deepfactor portal services depending upon the number of concurrent applications that are being observed. Please note, CPU and memory usage can vary based on the type 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 usage, spread across all nodes where the Deepfactor portal is deployed.
| Portal Size | Number of active containers (applications) | Number of inactive containers (applications) | CPU Usage | Memory Usage |
| OVA / AMI | 50 | 50 | 8 CPU | 32 GB |
| XS | 150 | 150 | 11 CPU | 7 GB |
| S | 400 | 400 | 14 CPU | 11 GB |
Legend:
- 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 usage: Number of CPUs used 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 used across all nodes where the Deepfactor portal is deployed. All nodes used for the Deepfactor portal should have a minimum of 4GB available.
For portal configurations requiring more than 640 active containers, contact Deepfactor.
#
SSL/Certificate Requirements #
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.
wget https://static.deepfactor.io/helm-charts/cert-gen/generate-cert.sh wget https://static.deepfactor.io/helm-charts/cert-gen/openssl-portal.cnf wget https://static.deepfactor.io/helm-charts/cert-gen/openssl-portalca.cnf
Run the script generate-cert.sh by providing the hostname you want to assign to your Deepfactor Portal:
chmod +x generate-cert.sh ./generate-cert.sh <deepfactor_portal_hostname>
Generate Kubernetes secrets using the following command:
wget https://static.deepfactor.io/helm-charts/prerequisite/df-certs.yaml.tpl wget https://static.deepfactor.io/helm-charts/prerequisite/prerequisite.sh
Run prerequisite.sh to create the deepfactor namespace and k8s secrets required by Deepfactor portal.
chmod +x prerequisite.sh \ ./prerequisite.sh portalkeypath="./portal.key" \ portalcrtpath="./portal.crt" \ portalcakeypath="./portalca.key" \ portalcacrtpath="./portalca.crt" \ pempath="./01.pem"
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 #
Inbound connections:
- TCP/443 – Telemetry data from observed applications
Outbound internet connections made by the Deepfactor portal:
https://resolute.deepfactor.io https://portalintegrations.deepfactor.io https://static.deepfactor.io
Package dependency database updates:
https://search.maven.org https://repo.maven.apache.org https://nvd.nist.gov https://registry.npmjs.org
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:
https://cve.mitre.org https://nvc.nist.gov https://secdb.alpinelinux.org https://repo.us-west-2.amazonaws.com https://alas.aws.amazon.com https://cdn.amazonlinux.com https://security-tracker.debian.org https://linux.oracle.com https://www.redhat.com https://git.launchpad.net https://people.ubuntu.com
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:
https://www.deepfactor.io/pricing
Please reach out to us by clicking the contact us button to obtain a license.
Notes #
- 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.