Introduction #
Deepfactor provides a mutating admission webhook that can seamlessly scan and observe your kubernetes workload containers. Deepfactor can automatically scan container images used by pods in your K8s cluster and also observe running containers for runtime security vulnerabilities. Deepfactor can also correlate the results of the two.
Deepfactor provides users the flexibility to turn on/off each of these modules (scan container images, observe running containers) at cluster and namespace level. Deepfactor also provides fine grained control for each of these modules. This article will describe the various options for container image scanning and observing runtime vulnerabilities. If you have not already installed the webhook in your cluster, please refer to the following document for instructions to install.
Install Deepfactor Kubernetes admission Webhook
During the course of the installation, you will have to provide a name for the cluster. After successful installation of the webhook, you will be able to see your cluster under ‘Kubernetes Clusters’ section of the portal UI.
The following sections will describe the options Deepfactor provides for Runtime and static scan modules.
Runtime security module options #
| Name | Description |
| Application Name | This option allows you to group pods into a single Deepfactor application. The common scenarios are
You can read more about this option here |
| Component Name | Choose how containers will be named within Deepfactor. The common scenarios are
You can read more about this option here |
| Component Version | Deepfactor allows you to version your container images. By default, this option is set to %imageTag%. |
| Environment Name | This optional parameter is used to represent the application’s execution environment. You can filter the results based on environment. |
| Include Pods | Selectors – You can define inclusion criteria for pods that you want Deepfactor to observe using a series of match expressions for pod labels similar to Set-based requirement of Kubernetes label selectors
You can read more about this option here |
| Exclude Pods | Regular expressions for pod names. Pods with name that match any of the specified regexes will not be observed by Deepfactor.
Regular expressions for container image paths. Containers with image path that match any of the specified regexes will not be observed by Deepfactor |
| Alert Policy | Deepfactor raises alerts based on policy rules. You can select the policy you would like Deepfactor to use to raise alerts for the cluster or namespace. |
| Exclude Job Pods | By default, Deepfactor will not observe pods created by K8s jobs and cronjobs. If you would like to observe them, please enable this option. Please note that K8s creates a random pod name for each of the job pods and this can result in a large number of unique components being created in Deepfactor. |
| Collect dependency usage | If this option is enabled, Deepfactor will intercept dependencies that are loaded during runtime and report that information in the UI. In addition, for java applications, Deepfactor will intercept class loaded event and provide a list of classes loaded per java dependency. This will help you know the extent of usage of a particular application dependency and help you priortize which vulnerable dependencies to remediate first. |
| Collect OS packages usage | If this option is enabled, Deepfactor will intercept OS package libraries that are loaded and report that information in the UI. |
| Enable logging | If this option is enabled, then Deepfactor will log debug messages within the pods to help debug any incompatibility noticed when running with Deepfactor. |
| Collect stack traces | If you enable this option, Deepfactor will collect language specific stack trace frames. Stack traces will help your developers narrow down the source of the vulnerability and remediate it. Please note, this is a resource intensive operation and it can add a non-trivial amount of resouce overhead. If you have tight limits set on your pods in K8s cluster, enabling this feature may even cause the pods to crash as it may reach the resource limits. |
| Collect HTTP URIs | If you enable this option, Deepfactor will intercept every HTTP call made to any port in the instrumented component and report the URI to the portal backend. You can see the full list of URIs on the Deepfactor portal UI. However, this can result in a lot of telemetry events being sent from your component to the backend resulting in overhead and high telemetry data volume. |
| Enable staged instrumentation | Deepfactor webhook monitors for restarts of instrumented pods. If a certain pod restarts multiple times, the webhook does not instrument the pod to avoid potential restart loops. The pod may restart due to hitting resource limits (possibly due to overhead added by Deepfactor), probe failures, incompatibility with Deepfactor instrumentation library, or an actual application pod bug.) |
| Abort Deepfactor instrumentation if pod restarts continuously | Deepfactor webhook monitors for restarts of instrumented pods. If a certain pod restarts more than the specified number of times, the webhook does not instrument the pod to avoid potential restart loops. The pod may restart due to hitting resource limits (possibly due to overhead added by Deepfactor), probe failures, incompatibility with the Deepfactor instrumentation library or an actual application pod bug. |
| OS Package manager query delay | Deepfactor queries the OS package manager to get full list and details of the os packages installed in your container. Since there can be several hundreds of packages installed, making multiple package manager queries at startup can cause a cpu consumption spike. In order to mitigate that, Deepfactor runtime library introduces a small delay between these queries. |
| Probe Increment Delay | Initialising telemetry collection might increase the application startup time, particularly for java applications. Deepfactor can automatically increment probe times to ensure probes don’t fail. Please configure these increment values appropriately if you notice pods failing to start due to probe failures. For more information on Kubernetes probes, please see documentation here. |
| Resource Increment | Deepfactor can automatically increase the memory and CPU limits of your pods to ensure there is additional room for the collection and transport of telemetry to the portal. Deepfactor recommends increasing CPU request and limit by 5%, and memory request and limit by 175Mi for a single process running in a pod and by 750Mi for ten processes running in a pod. For more information on Kubernetes managed resources, please see documentation here. |
SBOM and SCA module options #
You can enable or disable container image scanning for any of the namespaces in your K8s cluster using the Deepfactor portal UI.
| Name | Description |
| Include Pods | Selectors – You can define inclusion criteria for pods that you want Deepfactor to scan using a series of match expressions for pod labels similar to Set-based requirement of Kubernetes label selectors
You can read more about this option here |
| Exclude Pods | Regular expressions for pod names. Pods with name that match any of the specified regexes will not be scanned by Deepfactor.
Regular expressions for container image paths. Containers with image path that match any of the specified regexes will not be scanned by Deepfactor |
| Alert Policy | Deepfactor raises alerts based on policy rules. You can select the policy you would like Deepfactor to use to raise scan alerts for the cluster or namespace. If you do not specify this option, the policy that is set as default in the Deepfactor portal will be used. |
| Exclude Job Pods | If you enable this option, Deepfactor will not scan container images that get spawned as part of K8s cronjobs. |
| Exclude Init containers | If you enable this option, Deepfactor will not scan container images that get spawned as part of init containers. |
| Duration between successive scans of the same image | Deepfactor’s K8s scan pod automatically scans container images used by application pods in your cluster. In order to avoid scanning the same image multiple times in a short interval of time, Deepfactor provides this configurable parameter that decides the time interval between successive scans of the same container image. |
| Container image scan timeout | You can optionally specify a timeout in minutes and the scan will be stopped and marked failed when the timeout occurs. If you have a large image with several resources, you may need to use this option to ensure it is scanned. |
