-
-
Notifications
You must be signed in to change notification settings - Fork 5
Getting started: Baseline
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)
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.
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
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.
Redis, StixViz, Lightening-rod and Headlamp (you need to generate a Token)
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
and at the same time, the kprobes: