Runtime Radar: Installing and Configuring Container Security Monitoring in Kubernetes

Runtime Radar is an open-source software solution for monitoring security events at runtime and responding to incidents in containerized environments.
It is designed to bridge the gap between image scanning during the CI/CD phase and the actual behavior of containers during execution — since some threats arise only at runtime, such as mining processes, privilege escalation, unexpected network traffic, and others.
The project is licensed under Apache 2.0.

Why Use Runtime Radar

Main Advantages

• Monitoring of events during container runtime: protection not only at the build/deployment stage but also during operation.
• Centralized management of multi-cluster environments: connect multiple clusters under a unified control interface.
• Integrations with existing security and monitoring systems: supports syslog, SMTP, and webhook.
• Ability to create custom detection rules (signatures) in Go through the SDK.
• Built on modern technologies: eBPF + Tetragon (sensor) for tracking kernel and container events.

When It’s Especially Useful

• If you already have a container infrastructure (for example, Kubernetes) and want to enhance the security of running containers.
• If your infrastructure is distributed across multiple clusters and you need a single management point.
• If open-source, flexibility, and integrations with SOC/log systems are important to you.
• If you have a limited budget or are seeking an alternative to expensive commercial products.

Architecture (Overview)

The main components of Runtime Radar:

• Runtime Monitor: a configurable sensor for collecting container and kernel events (based on Tetragon/eBPF).
• Event Processor: an anomaly analysis engine (in some cases using a WebAssembly module).
• Cluster Manager: the module responsible for connecting clusters to a unified management console.
• Notifier: sends events to SOC/log systems via syslog/webhook/SMTP.
• UI (web interface): event visualization, incident management, filtering, and investigation.

Graphically: sensors in clusters → events → analysis engine → notifications/interface.

Prerequisites

Before installation, make sure your environment meets the following requirements:

• Container platform (e.g., Kubernetes) with administrative privileges in the cluster.
• Nodes where Runtime Radar will be deployed must support eBPF (Linux kernel with appropriate version and features).
• Access to the Helm chart or Docker images of the project (on GitHub).
• (Recommended) Logging or monitoring system (e.g., ELK/Elastic, OpenSearch, Loki) for integration.
• For multi-cluster environments — network and access preparation between clusters and the management console.
• Basic understanding of runtime container security (processes, privileges, network connections) is a plus.

Installation Steps

1. Clone the repository
   git clone https://github.com/Runtime-Radar/runtime-radar.git cd runtime-radar
2. Prepare the Helm chartThe install/helm directory contains the Helm chart for installation.
   If needed, customize the values.yaml file (integration addresses, namespace, permissions, etc.).
   Example:
   helm install runtime-radar ./install/helm -n radar --create-namespace
--set notifier.syslog.enabled=true
--set notifier.webhook.url=https://…
--set clusterManager.enabled=true
3. Deploy the sensor on nodesThe sensor should be installed on each node from which you want to collect events. Ensure kernel/container events are being captured (e.g., process launches, privilege changes, network connections).
4. Configure Rules (Policy / Rules)In the web interface or via SDK, you can apply pre-built monitoring policies or write your own signatures in Go.
5. Integrate with Notification/Logging SystemsSet up notifications through syslog, SMTP, or webhook. Choose message templates (uses Go template engine).
6. Verify Operation
   • Open the web console UI;
   • Check that sensors are connected and events are being received;
   • Run a test anomaly (for example, start a container with unusual behavior) and verify that the event is detected and a notification is sent;
   • Use filters and investigation tools: process visualization, parent/child relationships, event type, etc.
7. Multi-Cluster Deployment (if required)Connect additional clusters via the Cluster Manager following the documentation. This allows managing all environments from a single interface.

Configuration and Operation

Policies and Rules

• Use built-in default policies for a quick start.
• Set up filters: remove “noisy” events and focus on key incidents.
• Write custom signatures via SDK when needed — define what constitutes abnormal behavior in your environment.

Investigation Interface

• The UI displays events with icons, types, and process relationships.
• You can filter by cluster, node, pod, or signal type.
• For incidents: navigate from an event to its context (parent/child processes) to understand the full chain.

Integration with SOC/Logs

• Configure event log delivery to ELK/OpenSearch/Loki or other systems.
• Use webhook/SMTP for critical alerts.
• In message templates (Go-template), include key fields: timestamp, cluster, pod, process, rule, severity level.

Monitoring Performance

• Ensure sensors collect events without excessive load or noise.
• Regularly check for “silence” (no events) — this may indicate that a sensor is down or filters are too strict.
• Update rules as your infrastructure evolves: new services, containers, or behavior patterns.

Known Limitations and Considerations

• Like any runtime system, it consumes resources: sensors may use CPU/memory on nodes — test the load before deploying in production.
• Interpreting “anomalies” requires context: what’s normal in one environment may be suspicious in another; tailor rules to your specific infrastructure.
• If your infrastructure is highly distributed or has weak network links, connecting to the central console may require additional network/security configurations.
• Open source — great for flexibility, but it also means your team should be ready to engage with the community or adapt the project as needed.
• The project is relatively new (as of October 2025), so the ecosystem may not yet be as mature as commercial solutions.

Conclusion

Container security is not just a set of tools - it’s a mindset. Runtime Radar helps you face the runtime stage, where real uncertainty lives: new processes, unexpected connections, and configuration errors.

Don’t treat monitoring as a formality. Listen to your infrastructure like a living system — it has “symptoms” that must be detected in time.
Configure alerts that warn about real problems without creating noise.
And most importantly - make security part of your daily development cycle, not just a reaction to incidents.

Runtime Radar can be your container “stethoscope”: quiet, unobtrusive, yet saving time and nerves when something goes wrong.

FAQ - Frequently Asked Questions

• 1. Can I use Runtime Radar without Kubernetes?
  Yes. Although the main integration is with Kubernetes, you can install the sensor on regular container hosts (Docker, Podman). The key requirement is eBPF support in the kernel.
• 2. Will Runtime Radar conflict with other monitoring systems (like Falco or Prometheus)?
  No, it won’t. Runtime Radar works in parallel using eBPF hooks. However, if multiple eBPF-based tools are running, monitor kernel load carefully.
• 3. How often should I update the security rules?
  It’s recommended to review them at least quarterly or whenever major infrastructure changes occur (new microservices, Kubernetes updates, access policy changes).
• 4. What if the system generates too many false positives?
  Use filters and priority levels in the settings. Disable low-priority signals to focus on critical ones. Runtime Radar allows you to define custom rules tailored to your cluster.
• 5. Is Runtime Radar suitable for production use?
  Yes. Although the project is relatively young, it’s stable and actively developed. Test it in a staging environment first to assess sensor load, then roll out to production.