🔘Key Components

eBPF Sniffer

Purpose: Intercepts HTTP traffic by hooking into key system calls (accept, read, write, close) at the kernel level. Deployment: Runs as a DaemonSet in Kubernetes, ensuring coverage across all nodes. Value: Captures API traffic in near real-time with low overhead and no code instrumentation.

RabbitMQ (Message Queue)

Purpose: Acts as a scalable message broker between the Sniffer and Aggregator. Deployment: Runs as a Kubernetes Deployment in the same cluster.

Aggregator

Purpose: Collects, filters, and deduplicates HTTP session data before generating HAR files. Deployment: Runs as a Kubernetes Deployment, pulling data from the Sniffer via RabbitMQ. Responsibilities:

• Filtering irrelevant traffic.

• Deduplicating repeated sessions.

• Storing the last X sessions in memory.

• Providing an API to generate HAR files on demand.

Attacker Container (Soon)

Purpose: Accesses generated HAR files for automated security scanning and API testing. Deployment: Runs as a sidecar container within the Aggregator pod. Benefit: Enables seamless vulnerability testing without extra network hops.

Security & Trust Considerations

Minimal System Footprint

eBPF operates in a sandboxed environment at the kernel level, ensuring system stability with minimal overhead.

Controlled Access & Compliance

Strict access controls allow only authenticated users and designated microservices to request HAR files.

Filtered storage policies prevent the retention of unnecessary or sensitive data.

End-to-End Data Protection

All communication is encrypted between the Sniffer, Aggregator, and RabbitMQ.

Data remains contained within your Kubernetes cluster, ensuring isolation and security compliance.