Configure Deepfactor Kubernetes admission webhook

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.

 
configure-webhook-1.png

configure-webhook-2.png

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

  1. Every pod becomes a single application (%podName%)

  2. Pods that have a certain label and value become part of a single application (%labels.{x}%)

You can read more about this option here

Component Name

Choose how containers will be named within Deepfactor. The common scenarios are

  1. %containerName%: Deepfactor will pick the containerName field from your podspec for the component name.

  2. %podName%_%containerName%: If you have specified the same container name across different pods, you can use a combination of podName and containerName as the name of the component

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.
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.

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.

  1. 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.

configure-webhook-3.png

3. Click + Observe Namespace

configure-webhook-4.png

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.

configure-webhook-5.png

You will see the following screen with the namespace ‘prod-env’ added.

configure-webhook-6.png

b) Override Config Options

6. Select Override Config Options (turns into a wizard).

7. Click Next. Please edit the config options as required.

configure-webhook-7.png

8. Click Add New namespace.

configure-webhook-8.png

The following screen appears:

configure-webhook-9.png

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.

configure-webhook-10.png

 

The following screen opens.

configure-webhook-11.png

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.

 

Was this article helpful?
0 out of 0 found this helpful

Comments

0 comments

Please sign in to leave a comment.