Using Existing Kubernetes Cluster

This guide explains how to use the provisioning script for generating all the Kubernetes components needed to run MetaDefender Core in you already created K8S cluster that depending on some configuration options chosen it will adapt the helm chart values for configuring it properly.

Also includes the details needed to understand how to install MetaDefender Core using directly the Helm chart.

Flowchart for MetaDefender K8S Script

The following flow chart represents how the MetaDefenderK8S script will configure the environment based on the options selected for installing MetaDefender products in an already created cluster.

Summary options to be selected

1. Select your cluster context where you want to install the MetaDefender products

2. Access to the K8S cluster. Generate Ingress or provide own access.

   1. An Ingress will be create per each product flag added as parameter to the script
   2. Own Access, you decide how to access to the cluster so it won't generate any ingress for accessing

3. Have your own database or create new database

   1. Own database, will be asked if you want either

      1. the script to set up the credentials and database host url for you
      2. the script will just indicate the secrets to edit, later on by you, for connecting the MetaDefender Core with your database.

   2. Create new DB in K8S. It will generate a postgreSQL pod inside the cluster

MetaDefender K8S script details

• Script path: https://github.com/OPSWAT/metadefender-k8s/blob/main/metadefenderk8s.sh

• Programming Language: Bash

• Installation Pre-requisites for installing:

  • Helm
  • Kubectl

• MetaDefender Core License Key (Required with --mdcore parameter)

  • Set it in your local environment credentials under MDCORE_LICENSE_KEY

How to run script

./metadefenderk8s.sh install --mdcore --name <k8s-cluster-name>

Script Parameters

Install using the Helm chart

The MD Core k8s deployment can be performed directly using the provided helm chart in our public GitHub repo here and example configuration files for different environments are provided in the helm_charts directory.

Using the helm repository

The GitHub repository can be used directly as a helm repo:

helm repo add mdk8s https://opswat.github.io/metadefender-k8s/

helm repo update mdk8s

​

#Example installation command

helm install mdcore mdk8s/metadefender_core -f <CUSTOM_VALUES_FILE.yml>

Or the repository can be cloned locally:

git clone https://github.com/OPSWAT/metadefender-k8s.git metadefender

cd metadefender/helm_carts

​

#Example installation command

helm install mdcore ./mdcore -f <CUSTOM_VALUES_FILE.yml>

Storage

MD Core containers are stateless and don't require any persistent storage. If the PostgreSQL database is deployed in the cluster, then it's recommended to use persistent storage managed by a cloud provider.

The helm chart can be configured to use a custom storage class or persistent volume by setting the storage_provisioner value to custom, adding the Kubernetes yaml for the persistent volume claim in the storage_configs value and then using the pvc name in the storage_name value to tell the Postgres pod where to save it's files. Here's an example using managed storage in Azure:

storage_provisioner: custom       # Type of storage to use in the pod definition

storage_name: ocstorage           # Name of the PVC to use in the pod definition

​

storage_configs:          # Example using a PVC with dynamic provisioning from an existing storage class

  pvc-example:

    apiVersion: v1

    kind: PersistentVolumeClaim

    metadata:

      name: ocstorage

    spec:

      accessModes:

        - ReadWriteOnce

      resources:

        requests:

          storage: 1Gi

      storageClassName: managed-premium

When using an external database that is not deployed from the MD Core chart, the deploy_with_core_db value has to be set to false in order to not deploy an additional database from the chart.

Exposing MD Core

By default, the helm chart deploys a ClusterIP service for MD Core and this can be changed to any service type supported by the Kubernetes cluster. For example, a LoadBalancerservice type can be created by overwriting the service_type value in the md-core component:

core_components:

  md-core:

    service_type: LoadBalancer

MD Core can also be exposed using an ingress:

core_ingress:

  host: <APP_NAMESPACE>-mdcore.k8s  # Hostname for the publicly accessible ingress, the `<APP_NAMESPACE>` string will be replaced with the namespace where the chart is deployed

  enabled: true                     # Enable or disable the ingress creation

  class: nginx                      # Sets the ingress class depending on the installed ingress controller

Scaling MD Core

Multiple MD Core pods can be deployed by setting the replicasvalue in themd-core component:

core_components:

  md-core:

    replicas: 3

TLS Configuration

In case we want to use a self-signed certificate, we need to create the secrets with the crt and key

mkdir ~/cert

openssl req -new -newkey rsa:4096 -days 36500 -nodes -x509 -keyout ~/cert/mdcore.key -out ~/cert/mdcore.crt

​

# Needed to replace <user>. kubectl do not accept "~"

kubectl create secret generic mdcore-tls-cert --from-file=/home/<user>/cert/mdcore.crt -n default

kubectl create secret generic mdcore-tls-cert-key --from-file=/home/<user>/cert/mdcore.key -n default

We can set up the configuration parameters in the values.yaml file

# From Values.yaml

tls:

  enabled: false

ReadinessProbe:

  httpGet:

    scheme: HTTPS

livenessProbe:

  httpGet:

    scheme: HTTPS

Nginx Ingress Configuration

1. In case we want to use a self-signed certificate, we need to create the tls secret with the crt and key

mkdir ~/cert

openssl req -new -newkey rsa:4096 -days 36500 -nodes -x509 -keyout ~/cert/mdcore.key -out ~/cert/mdcore.crt

​

# Needed to replace <user>. kubectl do not accept "~". Also change <namespace>

kubectl create secret tls mdcore-tls --key="/home/<user>/cert/mdcore.key" --cert="/home/<user>/cert/mdcore.crt" -n <namespace>

2. Set up the following configuration parameters in the values.yaml file

# Ingress setting for md core (md core setting are ignored if deploy_with_core is false)

core_ingress:

  host: <APP_NAMESPACE>-mdcore.k8s       # Hostname for the publicly accessible ingress, the `<APP_NAMESPACE>` string will be replaced with the namespace where the chart is deployed

  service: md-core                  # Service name where the ingress should route to, this should be left unchanged

  port: 8008                        # Port where the ingress should route to

  enabled: true                    # Enable or disable the ingress creation

  class: nginx                      # Sets the ingress class

  tls: true                        # Flag for set up tls section in ingress

  secret: mdcore-tls                # SecretName of the tls secret created to be used for ingress

  ingress_annotations: 

    nginx.ingress.kubernetes.io/affinity: cookie     # To set affinity when having more than one pod running behind the ingress

3. Install MetaDefender Core using Helm
4. Install Nginx Ingress Controller (Example adapted to Azure, check your CSP to adapt the command to it)

helm upgrade --install mdcore-ingress ingress-nginx/ingress-nginx  --debug \

--create-namespace \

--namespace nginx-ingress \

--version 4.6.1 \

--set controller.replicaCount=2 \

--set controller.admissionWebhooks.patch.nodeSelector."beta\.kubernetes\.io/os"=linux \

--set controller.nodeSelector."beta\.kubernetes\.io/os"=linux \

--set controller.service.annotations."service\.beta\.kubernetes\.io/azure-load-balancer-internal"=false \ #Change to true if you want to have an internal load balancer

--set controller.service.annotations."service\.beta\.kubernetes\.io/azure-load-balancer-health-probe-request-path"=/healthz