Run your Kubernetes workload with Deepfactor

Introduction #

Deepfactor provides a mutating admission webhook that can seamlessly scan and observe your workloads running in on premise or managed kubernetes clusters such Amazon Elastic Kubernetes Service, Google Kubernetes Engine (GKE), Azure Kubernetes Service (AKS), Red Hat OpenShift etc. Deepfactor can also correlate the static scan and runtime behavior to help you not only unearth but also priortize vulnerabilities. If you would like to read more about Kubernetes mutating admission webhook, you can refer to the following Kubernetes documentation article.

Mutating Admission Webhook K8s Documentation

Deepfactor admission webhook controller works with K8s v1.23 and up

Prerequisites for installing Deepfactor Mutating Admission webhook #

1. admissionregistration.k8s.io/v1 apiversion should be supported
   

   kubectl api-versions | grep admissionregistration.k8s.io

   Output should have

   admissionregistration.k8s.io/v1

2. Mutating admission plugin should be enabled in kube-apiserver flags

   kube-apiserver -h | grep enable-admission-plugins

   Output should have the following in the list

   MutatingAdmissionWebhook

3. Ensure you have the following cluster level permissions
   In order to install the Deepfactor mutating admission webhook in your cluster, you will need permissions for admissionregistration.k8s.io/v1 api group. If you are using cert-manager to manage the webhook certificate, you will need permissions for certmanager.k8s.io api group as well. An example cluster role is shown below.

   apiVersion: rbac.authorization.k8s.io/v1
   kind: ClusterRole
   metadata:
     labels:
       rbac.authorization.k8s.io/aggregate-to-admin: "true"
     name: deepfactor-webhook-admin
   rules:
   - apiGroups:
     - "certmanager.k8s.io"
     resources:
     - issuers
     - certificates
     verbs:
     - create
     - update
     - apply
     - patch
     - delete
     - get
     - list
     - watch
   - apiGroups:
     - "admissionregistration.k8s.io/v1"
     resources:
     - mutatingwebhookconfigurations
     verbs:
     - create
     - update
     - apply
     - patch
     - delete
     - get
     - list
     - watch
   

4. Ensure you have the following namespace level permissions
   

   apiVersion: rbac.authorization.k8s.io/v1
   kind: Role
   metadata:
     namespace: df-webhook
     name: deepfactor-namespace-role
   rules:
   - apiGroups: [""]
     resources: 
     - secrets
     - services
     - configmaps
     - pods
     - deployments
     - jobs
     - horizontalpodautoscalers
     verbs: 
     - create
     - update
     - apply
     - patch
     - delete
     - get
     - list
     - watch

#

Install Deepfactor Mutating Admission Webhook #

Deepfactor’s mutating admission controller webhook can be deployed using helm charts. Detailed instructions can be found at Install Deepfactor Mutating Webhook

Configuring Mutating Admission Webhook #

The webhook can be configured with a list of namespaces along with defaults parameters per namespace. Each of these defaults can be overridden using specific annotations in pod specs. A detailed description of the webhook configs and annotations can be found at How To Configure Deepfactor Mutating Webhook

#

Deepfactor Kubernetes Webhook Operation #

Deepfactor admission webhook is a mutating webhook listening for ‘CREATE’ operation for resource type pods. Upon receipt of a valid mutation request, Deepfactor webhook checks the pod spec against the config specified by the user in the Kubernetes cluster/namespace configuration. If the pod qualifies for mutation based on the config, Deepfactor mutates the pod spec to include df-init and df-init-con-0, df-init-con-1, …, df-init-con-N init containers where N represents the number of containers in the pod being mutated.

For example, for a two container pod, there will be three init containers injected by Deepfactor: df-init, df-init-con-0 and df-init-con-1.

The first and the common init container, df-init copies Deepfactor interception library into an empty dir persistent volume (df-data) provisioned per pod. The subsequent init containers are specific to the container being instrumented. The init container uses the same container image as of the container being instrumented. This init container runs a series of compatibility checks to ensure Deepfactor can instrument this container image. If these tests succeed, Deepfactor injects the interception library into the container and also updates the LD_PRELOAD env variable.

Any failure at any stage of the mutation process results in a graceful bailout of Deepfactor instrumentation and the application will be deployed without Deepfactor.