Skip to content

Getting started: Baseline

Duck edited this page Feb 6, 2025 · 3 revisions

Using Kubescape's Application Profiles to record known behaviour

We currently have two ways of detecting anomaly: one is unknown hashes in the kprobes and the second is the inspector-gadget functionality to profile sys-calls and file-access. This page describes the settings and setup to use them in conjunction with maximal efficiency.

First, we don't directly use inspector-gadget but kubescape, as it has other wonderful usability functions ( Many Thanks to all upstream maintainers)

Timing

To record the baselines in a predictable way, we must ensure that all profiling is done at the beginning of the setup, only.

WIP: save/restore of previous applicationprofiles to be used during analysis for cross-correlation with the timeseries logs.

Honey-up

Use the main Makefile to deploy honey-up , this includes kubescape with runtimeDetection enabled. You might need to play with the honeystack/kubescape/values**.yaml specifically the path to runc (Docker-Desktop is not supported btw) and the memory usage of the kubescape-operator. The two examples work for a 4-node GKE and a kind , both 1.31.xx

Add YourApp

We are using Harbor as a sample-application via make sample-app, adapt to YourApp such that it is installed at the same time as the honey-stack components.

In the following example, note that most namespaces are excluded from the kubescape scanning, which in a real lightening attack you might want to include for maximal attack-path testing.

Port-forward

Redis, StixViz, Lightening-rod and Headlamp (you need to generate a Token)

Check the profiles

Launch lightening

Make sure the check.sh script does what you want it to , then make lightening and wait for all logs to stop accumulating, then make lightening-off

You will now see the Unexpected events Screenshot 2025-02-06 at 22 52 33 and at the same time, the kprobes:

Screenshot 2025-02-06 at 22 54 09

Clone this wiki locally