feat: docs

ebpf/analogy.md

@@ -0,0 +1,44 @@
+# Here actual EBPF analogy is documented what are we using exactly
+
+## Inodes
+
+* In ext4 systems we get to see inodes
+
+* Here is a reddit post if you want to read more about it.
+
+* They are unique ids for a single file which can be used for filtering
+
+* For ntfs file system the unique id changes to a 8 bit hash
+
+## BPF Maps
+
+* These are used for storing inodes where we use lookup function to get logs of exact file provided via cli
+
+* Events & structures are transferred in maps
+
+## BPF RING BUFFER
+
+* This is a kind of map
+
+* This is use to save logs into memory incase the machine gets slower. By incorporating it we can ensure that logs are not being dropped
+
+* Memory limit increases, along with max entries are 4096, 8192, 16384, 32768
+
+* More on Map Type 'BPF_MAP_TYPE_RINGBUF' - eBPF Docs 
+
+## BPF Per CPU Array
+
+* Kind of a map to store struct in memory
+
+* In order to tackle storage issue as ebpf provides only 512 bytes of storage we preferred BPF_PERCPU_ARRAY which means that only we can utilize storage upto 32KB
+
+* This per-CPU version has a separate array for each logical CPU.
+
+* More on ebpf.io
+
+## EBPF Debug logs
+
+* These are located in /sys/kernel/debug/tracing/trace_pipe
+
+* Do a cat command on the above to read it
+

ebpf/architecture.md

@@ -0,0 +1,39 @@
+# Architecture
+
+![1752410338305](../image/architecture/1752410338305.png)
+
+## Daemonset
+
+* This will be golang code which will query into cgroup using k8s api and would bring in the actual path of file instead of regex
+* These path will be added into CRDs itself. Piece by Piece they will be added
+* Whenever their is rename or delete event then these paths will be changed accordingly by StatefulSet
+
+## StatefulSet
+
+* This is where we insert kprobes into the kernel
+* It will listen to the ebpf logs and print them
+* They can be eventually be recorded by loki and can be seen in grafana
+* It can also modify crds whenever there is delete or rename event
+
+## CRDs
+
+* These CRDs can be like
+* These CRDs will be used by daemonset to send information to ebpf program in the linux kernel
+* Regex to be used exclusively
+* They can be in different namespace as it will be applied on pods that are there
+* We can have a global monitoring policy as well
+
+```yaml
+apiVersion: sentinelfs.io/v2
+kind: FileMonitoringPolicy
+metadata:
+  name: monitor
+spec:
+  podSelector:
+    labels:
+      - key: app
+        value: pipeline
+  files:
+    - path: /app/*
+    - path: /etc/secrets/*
+```

product/ebpf_based_file_monitor.md

@@ -0,0 +1,21 @@
+# What is EBPF?
+
+A debugger on Linux kernel
+
+## What are we building?
+
+A stealthy debugger that can record unexpected file operation done in a project directory which indeed can detect the vulnerabilities if container process is able to access certain file in a non intended way
+
+So it is basically container testing tool to detect file access which was not suppose to happen
+
+## Why a container testing tool?
+
+There is a single tool that can do everything from file monitoring to network monitoring. That is falco
+
+We do not get a specific tool for actual file testing or we get tools that do not work on container. Here are some example fanotify and auditctl
+
+Testing is usually preferred on low end hardware so building is specifically for k3s may be good as k3s is basically light weight kubernetes
+
+This is would help the user of this product to actually see how much is their container Harding actually working
+
+Here is a rough architecture of the project