Splunk helps security and operations teams make sense of machine data. That creates an interesting infrastructure challenge inside Splunk itself: the systems behind the Splunk platform also need security data that is rich, consistent, and usable by the teams responsible for detection and response. Splunk uses Isovalent Runtime Security, (the enterprise, hardened edition of Tetragon), to protect systems that run the Splunk platform. Tetragon gives Splunk kernel-level visibility into runtime activity and sends that telemetry into Splunk, where Detection Engineering teams can use it to alert the SOC, investigate emerging threats, and enrich other security data. For Splunk, the value is both technical and operational. Tetragon improves runtime visibility across Kubernetes and virtual-machine environments, while reducing the overhead that came with older sidecar-based security telemetry. “We use Tetragon to help protect the systems behind Splunk with the same kind of rich, actionable telemetry our customers expect from us. It gives our security teams kernel-level runtime visibility they can bring directly into Splunk for detection, investigation, and response.” Richard Wilhite, Senior Staff Security Engineer, Splunk What Splunk Needed From Runtime Security Splunk operates at large public-cloud scale, with approximately 170,000 cloud resources supporting Splunk software development, Splunk Cloud, Splunk Observability Cloud, and related environments. Before adopting Tetragon, runtime visibility depended on multiple security services, many of which were not Kubernetes-aware. Each service had to be maintained and supported separately, and policies could require different implementations between virtual machines and Kubernetes. Splunk's Tetragon deployment now spans tens of thousands of virtual machines and dozens of Kubernetes clusters, with expansion planned across additional Splunk environments. Splunk needed a runtime security approach that could work natively in Kubernetes, extend across virtual machines, and feed high-quality telemetry into Splunk itself. The goal was to improve observability and detection while reducing the operational cost of maintaining separate security data paths. Why Isovalent Runtime Security Tetragon is built on eBPF, which allows it to observe runtime activity directly from the Linux kernel. That gives teams visibility into events such as process execution, file activity, and network connections without relying on application sidecars for every workload. For Splunk, that model matched the environment. Kubernetes was a central part of the platform, but virtual machines remained part of the operating reality. Splunk needed Kubernetes-aware runtime telemetry that could also extend across Linux systems, support a multi-cloud footprint, and flow into Splunk for detection and response. Isovalent Runtime Security gave Splunk an enterprise-supported way to run Tetragon across that environment. It helped Splunk consolidate runtime visibility, reduce dependence on older sidecar-based telemetry, and give security teams richer context from the systems running the Splunk platform. The Solution: Tetragon Data Into Splunk Splunk uses Tetragon to monitor large parts of its cloud environment. Tetragon telemetry is sent into Splunk, where Detection Engineering teams use the data to provide alerts to the SOC, respond to emerging threats, and enrich other security signals. The deployment model reflects the shape of Splunk's infrastructure. Splunk uses Helm and CI/CD automation to deploy Tetragon across Kubernetes clusters, and Puppet for systemd-based virtual-machine deployments. Tracing policies and alert rules are managed through the same automation paths, helping teams keep runtime security closer to the way the platform is operated. That gives Splunk a more consistent way to collect and use runtime data across Kubernetes and virtual-machine environments. Instead of maintaining separate security services for each infrastructure pattern, Splunk can use Tetragon as a common source of process, file, and network activity. That consolidation brings several runtime security needs into one telemetry path: Visibility into process execution, filesystem activity, and network connections. Kubernetes-aware context that can be correlated with runtime events. A common approach across Kubernetes clusters and virtual machines. Runtime telemetry that can flow directly into Splunk for SOC alerts, threat response, and security enrichment. More control over what security events are gathered and how they are used. The telemetry becomes more useful once it is in Splunk. By correlating Kubernetes API metadata with process, file, and network events, Splunk can shorten root-cause analysis, inform response actions, and clarify incident scope. Tetragon data can also be combined with other data sources, including CVE context, to improve detection workflows. The Outcome: More Visibility, Less Overhead The most significant benefit of this solution was improved security visibility through Splunk, paired with lower operational overhead than the previous approach. In Kubernetes environments where Tetragon replaced prior sidecar-based security telemetry, Splunk saw a 66.5% reduction in CPU utilization and a 74% reduction in memory utilization. That matters because runtime security data is only useful if teams can collect it without adding unnecessary load to the platform they are trying to protect. The below metrics show the outcomes achieved by the Splunk team. Represented in red is the data from their legacy data collection services, and represented in green is the reduced overhead achieving the improved outcomes by implementing Isovalent Runtime Security, the lower number represented on the line graphs show the improvements in reduced CPU and Memory usage. By consolidating those runtime security needs through Tetragon, Splunk improved visibility into runtime activity, reduced the effort required to maintain security services, and gave its Detection Engineering and SOC teams better context for investigation and response. The result is a cleaner operating model: collect runtime activity close to the kernel, send the data into Splunk, enrich it with the context security teams already use, and apply it to detection and response workflows. “With Tetragon, we improved runtime security visibility while reducing the overhead of collecting it. That combination makes security telemetry easier to operate and more useful for investigation and response.” Richard Wilhite, Senior Staff Security Engineer, Splunk The Value of Enterprise Support Splunk had experience with Tetragon before the enterprise support relationship, but running runtime security across large production environments introduced practical challenges. The team needed help tuning configurations and policies and making telemetry ingestion reliable at scale. Isovalent support changed that operating model. With prioritized ticket handling and direct guidance, Splunk could troubleshoot faster and operate Tetragon with more confidence. When kernel incompatibilities affected certain Kubernetes nodes, Splunk engaged Isovalent's support team and worked with them to diagnose the issue and move toward a fix. That kind of support matters when runtime security is part of the production foundation. When the environment is complex and the stakes are high, access to the expertise behind Tetragon is invaluable. FAQ: What Other Security Teams Can Learn Why does Kubernetes-aware runtime visibility matter? Security teams need context that matches the way modern platforms run. Tetragon gives teams visibility into process execution, file activity, and network connections, with Kubernetes context that can help investigations move faster. What changes when runtime telemetry flows into the SIEM? The data becomes part of the workflow security teams already use. For Splunk, Tetragon telemetry flows into Splunk, where teams can alert, investigate, enrich, and respond using a familiar platform. Why consolidate across Kubernetes and virtual machines? Many organizations still run both. A common runtime security approach reduces the need to maintain separate tools, policies, and telemetry paths for each infrastructure pattern. Why does overhead matter? Security telemetry must be efficient enough to run broadly. Splunk's experience shows that teams can improve runtime visibility while reducing CPU and memory utilization from older telemetry approaches. Build Runtime Security into the Platform Platform and Security teams are being asked to cover more infrastructure, more workloads, and more deployment models. Kubernetes has changed how applications run, but many organizations still operate virtual machines alongside clusters. Both Platform and Security teams need visibility that can meet both realities. Isovalent Runtime Security gives teams an enterprise-supported Tetragon foundation for observing and enforcing runtime behavior across Kubernetes and Linux environments. It helps teams collect the data needed for detection and response, reduce operational overhead, and build runtime security into the platform itself. Are you facing similar security challenges in your platform today? Reach out to the Isovalent team to discuss how eBPF powered solutions like Isovalent Runtime Security, can help you provide more effective security observability signals and enforcement capabilities. Learn More: Learn more about Isovalent Runtime Security Explore Isovalent labs and get hands on with Tetraton and Isovalent Runtime Security Read more Isovalent case studies