Introduction
Deepfactor provides a mutating admission webhook for instrumenting your K8s workloads with Deepfactor. This article will describe how to configure the webhook to observe pods in your namespaces once you have successfully installed the webhook. 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.
Deepfactor provides an extensive set of options for you to configure the webhook to suit the way your organization deploys workloads into kubernetes clusters. You can set these options at cluster level and override them per namespace if you would like to customize certain options for your namespace.
The options are explained in the table below along with their default values
Webhook instrumentation config 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%. However, if you do not use tags to version your container images, pick the %imageID% option |
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. |
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. |
Enable method tracing |
Enabling this option will result in Deepfactor tracking all the java methods invoked by your application at runtime. Since this operation intercepts every method invoked, it can add a non-trivial amount of overhead, particularly at startup depending upon the complexity of your application. 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 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. |
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.) |
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. |
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. |
Observing a namespace with Deepfactor
Once the webhook is successfully installed and configured, you can specify the namespaces in your K8s cluster, you want to observe with Deepfactor.
-
From the left-side navigation menu, click ‘Kubernetes Clusters’.
A new page opens that has a list of Kubernetes Clusters that Deepfactor observes.
2. Click on the cluster name in which the namespace you like to observe exists.
3. Click + Observe Namespace
Please enter the name of the existing namespace in the cluster. You can inherit the namespace configuration from the cluster configuration or if you would like to customize certain options, you can click on ‘Override Config Options’.
a) Inherit from Cluster Config
4. Select the Inherit From Cluster Config option.
5. Click Add New namespace.
You will see the following screen with the namespace ‘prod-env’ added.
b) Override Config Options
6. Select Override Config Options (turns into a wizard).
7. Click Next. Please edit the config options as required.
8. Click Add New namespace.
The following screen appears:
Please note, it may take up to two minutes for the webhook config to refresh. Once webhook config is refreshed, Deepfactor will observe pods that get created in the namespace as per the config options specified in the steps above and you will be able to see insights related to them on the portal UI.
Editing namespace configuration
Deepfactor allows you to update cluster as well as namespace configuration from the UI.
1. Click on Edit Namespace Config.
The following screen opens.
You can edit the configuration options as per your requirement and click Save. Please note, it can take up to two minutes for the webhook to pull the latest configuration.
Comments
Please sign in to leave a comment.