Summer is here and it’s full of development and collaboration, we’re thrilled to announce the v1.16 release of Isovalent Runtime Security! This release expands observability and control beyond Kubernetes, bringing powerful capabilities to hybrid and non-Kubernetes workloads, including an exciting integration with Cisco Nexus switches. With features across centralized policy management, real-time alerting, and CVE mitigation, v1.16 helps Security and Platform teams glean deeper insights into their application behavior, secure diverse environments, and proactively detect threats in real-time. If interested in a specific feature, feel free to navigate directly below or reach out for a demo. What’s new in Isovalent Runtime Security Simplify policy management across non-Kubernetes environments: Implement consistent security policies across non-Kubernetes and hybrid environments (more details) Improved hook into Kubernetes metadata: Improved Kubernetes metadata capture for container insights (more details) Flexible, lightweight alert rules: Proactively identify threats with custom alert rules (more details) Isovalent + Cisco protecting Nexus switches: Monitor and mitigate runtime security threats on switches, without the need for restarts (more details) Simplify policy management across non-Kubernetes environments Tracking security policies across diverse environments often requires separate tools and workflows, leading to inefficiencies, inconsistencies, and increased overhead for Security and Platform teams. Now, enforce consistent security policies across Kubernetes and non-Kubernetes environments. No more juggling multiple control planes to handle different target workloads. v1.16 brings a new control path called tetragonMandate, which provides a centralized control plane for managing security policies across non-Kubernetes environments, such as virtual machines or data centers. For example, many companies deploy physical servers at remote locations such as offices, retail stores, or manufacturing plants. These bare-metal devices run critical applications but are not typically managed by Kubernetes. With tetragonMandate, security teams can apply the same security policies to these edge servers as they do to their Kubernetes clusters or VMs. This allows SecOps teams to control and monitor security settings on physical devices like network appliances, IoT gateways, or industrial control systems from a single platform. Policies are managed via a configuration file (YAML) accessible via URL, providing the same dynamic updates without agent restarts that Tetragon users are familiar with. See the example policy below of a tetragonMandate configuration. Let’s break this config file down: info: Metadata to describe the policy for better version control and documentation. conf: Defines global settings through mode. mode: Specifies whether the policies are monitor (observe only) or enforce (actively restrict behavior). policies: List individual security policy files to be applied. url: Points to the external YAML file defining the policy. conf (optional): Overrides the previously defined global mode for this specific policy (e.g., enforce mode for policies/2.yaml). Teams simply specify the policy files, plus whether the policy is a monitoring or enforcement permissioned policy. Then, target workloads immediately apply policies with no restart or downtime. tetragonMandate is an exciting leap forward, bringing Tetragon’s leading eBPF security use cases to non-Kubernetes workloads, and be on the lookout for a deep dive blog going live soon. Improved hook into Kubernetes metadata Inconsistent or unreliable container runtime metadata can lead to incomplete event correlations, making it difficult for teams to get clear runtime security and application visibility. A more reliable hook into the container runtime spells good news for all the top runtime security use cases, whether you are looking to track known CVE’s, audit and protect file operations, monitor network performance, and more. As covered in previous releases (ex: v1.14, v1.13), hooking correctly into the container runtime (CRI-O, Containerd, runc, and more) is fundamental to capturing Kubernetes metadata. This identity metadata is then used for correlating what events happened where, so the right context gets surfaced with each event. This release improves the Kubernetes pod association process by resolving corner cases around cgroup. v1.16 replaces cgroup names with cgroupIDs for associating container processes with Kubernetes pod metadata. This resolves unique cases where cgroup names are unreliable (e.g. below with CRI-O + runc), keeping accurate Kubernetes metadata association for runtime security use cases. For example, in environments like CRI-O with crun, the cgroup name retrieved via eBPF may default to a generic string such as "container" which cannot be mapped to a Kubernetes Pod. By using cgroupIDs, a unique and stable identifier, Isovalent reliably maps container events such as file operations or network activity to the correct Kubernetes metadata. Flexible, lightweight alert rules A common problem we see across teams is the struggle to balance actionable threat detection with the overwhelming volume of event data generated, inevitably delaying any ability to quickly respond to critical incidents. One of the best quality of life features for Tetragon is how easy it is to pipe events to a preferred SIEM or logging backend (like Splunk), this is important for building complex rules and analyzing security data. Building on that value, for teams looking to implement lighter, rapid alerts there is now an answer within Tetragon itself! Isovalent introduces the new AlertRule CRD, providing the foundation for real-time threat detection workflows within Tetragon. This feature enables users to define custom alert rules based on Tetragon events, triggering real-time notifications when suspicious activity is detected. Notably, this brings threat detection logic closer to the point of data collection. Rather than having all rules in a SIEM on top of already exported data, SecOps teams can write detection queries on Tetragon data at the agent level. This extends the benefits from faster alerts into lower resource utilization, as the entire host is being continuously monitored, but telemetry is surfaced only if the AlertRule is triggered. Platform and Security teams are already implementing AlertRules to surface specific events, while keeping the overall noise of their event stream low. When building an alert, users define the severity (info, warning, or critical), can generate a message (human-readable text or even a link to a CVE), and create custom tags to sort and filter to a specific framework (ie MITRE ATT&CK mapping). With these rules, security teams are monitoring for specific suspicious activities such as shell executions, AWS credential searches, and other security-significant events that require you to move fast and limit a blast radius. Breaking this down, the policy detects attempts to search for AWS credentials (like access keys or tokens) using commands grep or find. Specifically, this watches for processes and flags suspicious activity when keywords AWS_ACCESS_KEY_ID or AWS_SECRET_ACCESS_KEY appear in the command arguments. When triggered, Isovalent sends a high-severity alert with the message "AWS credential hunting detected", helping teams respond quickly without needing additional data processing steps. The goal here is not to replace complex threat detection, but to provide teams with a flexible and lightweight option for a real-time alert path. For example, consider a server hosting sensitive data where deny-listed system calls such as ptrace or execve are strictly prohibited. In this scenario, we have a clear definition of known-bad-behaviors that do not require complex correlations or conditional logic to trigger escalation. Simply apply the CRD and monitor for these specific events to immediately generate an alert when they occur, eliminating the need for further analysis or historical event correlation. This approach allows for easier rapid detection and response to high-priority threats. Isovalent + Cisco protecting Nexus Switches Protecting against new vulnerabilities is a race against time. Cisco and Isovalent are closing that time window. Patching critical infrastructure often requires disruptive upgrades or downtime, leaving teams struggling to maintain both security and operational continuity. Attackers start working on exploits in mere hours after new CVEs are published. Delays in protecting against these exploits threatens network infrastructure, and by extension the entire enterprise. Cisco Nexus switches just got smarter and stronger. Now, Nexus + Isovalent are better together with deep integrations to monitor and audit your switches against known CVEs, with no downtime or performance impact. “When you have a vulnerability there will be a compensating control, a shield, that will be applied to the vulnerability within minutes. And then over time as you have a patch, the vulnerability will get taken away.” Jeetu Patel, President and Chief Product Officer at Cisco This integration brings Tetragon into Cisco Nexus 9300 and 9400 fixed form switches to detect and mitigate against runtime threats without requiring switch upgrades and reboots. Security teams can proactively monitor, harden, and secure Nexus switches while maintaining uptime. Deep security visibility: Monitor runtime executions, network connections, and high risk system calls to detect threats and respond quickly. Enforce a security baseline policy: Harden switches by sandboxing processes and limiting untrusted or risky behaviors, reducing exposure to zero-day attacks. Monitor and audit against new CVE’s: Identify vulnerabilities with potential for privilege escalation or unauthorized access, enforcing proactive mitigation and compliance. Want a closer look? See the walkthrough below of Isovalent’s Runtime Security (Tetragon) deployed on a Cisco 9000 series switch, and using Splunk to surface up insights and enforcement details. Learn more! Isovalent brings a new level of runtime security with powerful visibility into Cisco Nexus switches, expanding beyond Kubernetes, and pushes teams with real-time alerting and centralized policy management. Whether you're securing hybrid environments, hardening your infrastructure against vulnerabilities, or streamlining threat detection, Isovalent are the leaders in bringing out the best of eBPF. Ready to take control of your security posture and gain deeper insights into your systems? Start exploring today, reach out for a deeper dive, and see how we can work together to simplify and strengthen your approach to runtime security. Request a Demo – Schedule a demo session with an Isovalent Solution Architect. Try Isovalent Runtime Security in a hands-on lab, earn a badge and progress down the Security Engineer Track. Learn more about Isovalent, Tetragon, and Cilium at our resource library – It lists guides, tutorials, and interactive labs. Get the Security & Compliance White Paper – the 25+ page blueprint for Kubernetes compliance. Extract security data no one else can with the host-based Kubernetes visibility solution brief.