Open-source Kubernetes runtime security: Falco vs Tetragon vs Tracee

Which Kubernetes runtime security tool fits your team

If your platform or security team needs runtime detection on Kubernetes and already runs a SIEM, start with Falco when alert-driven detection, broad event sources and CNCF graduation matter most. Choose Tetragon when you need filtering and blocking inside the kernel, with Kubernetes-aware identities such as namespaces and pods. Choose Tracee when eBPF-based forensics and event depth matter more than a policy-first model. KubeArmor is also available as a fourth option, but this comparison does not carry detailed facts for it, so evaluate it separately before shortlisting.

Falco's strength is its alerting model. It documents rules that send alerts to standard output, a file, syslog, a program or an HTTP(S) endpoint, and Falcosidekick forwards events onward. Its plugins add sources beyond system calls, including Kubernetes audit logs. Falco's documentation describes alerting and forwarding, not blocking, so if your SIEM or response tooling will act on alerts, this model fits. If you need the kernel to stop an action before it completes, Falco alone does not meet that need. Confirm with the Falco project which enforcement path it supports in your version.

Tetragon applies policy inside the kernel, which its documentation says reduces overhead for high-frequency events, and it can kill a process when its privileges change before the system call completes. The condition is kernel knowledge: the Tetragon documentation warns that tracing policies require familiarity with the Linux kernel and containers to avoid problems such as TOCTOU bugs. Plan for that skill in your platform team. Tracee suits teams whose priority is detailed event records, including process lineage, file paths and network connections, for security monitoring, compliance, troubleshooting and forensics. Before committing, validate each tool on a staging cluster with your own privileges and Helm or DaemonSet settings, and ask each vendor for the current supported kernel and Kubernetes versions.

Which tool fits which scenario

This table maps common Kubernetes runtime security scenarios to the tool whose documented behavior fits best. Read each row as a starting point: confirm the fit against your kernel versions, cluster setup and response workflow before you commit.

Scenario	Best-fit tool	Reason from documented behavior
Alerting into an existing SIEM or log pipeline	Falco	Falco delivers alerts to standard output, a file, syslog or an HTTP(S) endpoint, and Falcosidekick forwards events to many channels. Wazuh publishes a K3s integration that reads Falco JSON events through an agent.
Blocking a process before a system call completes	Tetragon	Tetragon can filter, block and react to events in the kernel, for example killing a process when its privileges change. Falco documentation describes alerting and forwarding, not blocking, so plan a separate enforcement path if you use Falco.
Forensic event capture with process lineage	Tracee	Tracee events include process lineage, file paths and network connections, and its documented use cases include forensics. Confirm that its event volume and storage fit your retention needs.
Kubernetes audit log correlation	Falco	Falco plugins document Kubernetes audit logs as an event source, so audit events can sit alongside system call detections in one rule set. Confirm the plugin setup in your cluster.
Cloud control plane log correlation	Falco	Falco plugins document AWS CloudTrail and Okta as sources. Tracee and Tetragon documentation in the supplied facts focus on kernel events, so confirm any cloud log source before relying on it.
Workload-level policy aimed at namespaces and pods	Tetragon	Tetragon is Kubernetes-aware and understands namespaces and pods, so policies can target individual workloads. Writing TracingPolicy objects requires kernel and container knowledge to avoid issues such as TOCTOU bugs.
Running outside Kubernetes or in a privileged container on a host	Tracee	Tracee runs as a privileged Docker container with host PID and cgroup namespaces, or as a DaemonSet through its Helm chart. Review the privilege model with your security team before deployment.

How eBPF design changes what each tool can do

All three tools use eBPF, but they differ in where a decision is made. Falco detects and alerts: its documentation describes alerts being forwarded to other components to take action, and it does not describe Falco itself blocking activity. Tetragon applies policy and filtering inside the kernel and can act directly, for example by killing a process when its privileges change before the system call completes. Tracee is built around real-time monitoring of system calls, network activity and file operations, with detections and forensic-grade event lineage rather than in-kernel enforcement. If your requirement is to stop an action at the moment it happens, Tetragon is the only one of the three whose documentation describes that behavior. Confirm the enforcement path you need against each project's current documentation before you commit.

Falco's default driver is the modern eBPF probe, built on the CO-RE paradigm. Falco also documents a kernel module, which remains an option where the eBPF probe does not fit your kernel. Choose the driver during the pilot, not after rollout, because it determines which hosts and node images you must validate and how you test upgrades to the kernel. Ask your platform team which kernel versions and node operating systems your clusters run, then check them against the driver requirements in the Falco documentation at Falco documentation. Plan the same kernel inventory for Tracee, which runs as a DaemonSet through the aqua/tracee Helm chart or as a privileged container.

Writing Tetragon tracing policies requires working knowledge of the Linux kernel and containers. A TracingPolicy hooks kprobes, tracepoints and uprobes, and the Tetragon documentation warns that careless hooks can introduce issues such as TOCTOU bugs. Budget time for kernel-aware engineers to write, test and review policies, and for a staging cluster where enforcement actions can be trialed without disrupting production workloads. Falco rules and Tracee policies carry a lower barrier for detection-only use, but the same review discipline applies to any rule that could be tuned into a blind spot. Treat policy authorship as a controlled change with peer review and version control from the start.

Capability comparison across Falco, Tetragon and Tracee

This table compares Falco, Tetragon and Tracee on license, release, eBPF approach, enforcement, Kubernetes awareness, rule formats, event sources, outputs and deployment. Read it as a starting checklist: where a cell says to confirm, verify that capability in the current docs or your own test cluster before you rely on it.

Capability	Falco	Tetragon	Tracee
License	Apache-2.0	Apache-2.0	Apache-2.0 (Aqua Security open source project)
Latest supplied release and date	0.45.1, October 19, 2026	1.7.1, August 25, 2026	0.24.1, November 19, 2025 (latest on the releases page supplied)
eBPF approach	Modern eBPF probe (CO-RE, default) or kernel module driver	eBPF-based observability and enforcement with kernel-side policy filtering	eBPF monitoring of system calls, network activity and file operations
Enforcement or alerting	Alerting on custom rules; documentation does not describe Falco itself blocking activity	Can filter, block and react in the kernel, such as killing a process before a system call completes	Detection and monitoring; confirm whether any response actions are configurable in your version
Kubernetes awareness	Runtime security across hosts, containers, Kubernetes and cloud; Kubernetes audit logs as a plugin source	Understands namespaces and pods so policies can target individual workloads	Deployable as a DaemonSet via the aqua/tracee Helm chart; confirm workload-level fields in your version
Rule or policy format	Custom rules	TracingPolicy custom resource (kprobes, tracepoints, uprobes), also loadable with the tetra CLI	Policies with scopes and rules, used through the CLI or on Kubernetes
Event sources and plugins	System calls plus plugins such as Kubernetes audit logs, AWS CloudTrail and Okta	Kernel function hooks, filtered on arguments and return values	System calls, network activity, file operations; process lineage, file paths and network connections
Outputs and metrics	Standard output, file, syslog, program or HTTP(S); Falcosidekick forwards to many channels	Confirm export and SIEM integration options for your version	Prometheus metrics, health endpoint and the traceectl CLI for streaming events
Deployment method	Host or cluster install with eBPF or kernel module driver; Wazuh publishes a K3s integration	Kubernetes deployment with policies applied as custom resources, or outside Kubernetes	Privileged Docker container with host PID and cgroup namespaces, or Kubernetes DaemonSet
Governance	CNCF Graduated since February 29, 2024; originally created by Sysdig	Cilium project; confirm governance model and maintainer base	Aqua Security open source project; confirm current maintainer activity

Rule and policy formats: custom rules, TracingPolicy and scoped policies

Falco detection logic lives in custom rules that match events from its drivers and plugins, then emit alerts. Rules are written in Falco's own rule language, so the people who maintain them need to understand the system call and event fields they reference. Falco's alerts are the product's main output, and the destination you choose determines how alerts reach your team. The Falco documentation describes delivery to standard output, a file, syslog, a spawned program or an HTTP(S) endpoint. Falcosidekick is the companion component that forwards Falco events to many applications and channels, so most production teams adopt it instead of building their own forwarders.

Output channels: Standard output, file, syslog, a spawned program and HTTP(S) endpoints are all documented alert destinations.
Falcosidekick: It fans events out to downstream tools, which removes custom glue code but adds one more component to patch and monitor.
Plugin fields: Rules can reference fields from plugin sources such as Kubernetes audit logs, AWS CloudTrail and Okta, not only system calls.
Skill required: Rule authors need to know Falco's condition syntax and the fields exposed by each driver and plugin.
Enforcement boundary: The documentation describes alerts forwarded to other components for action and does not describe Falco blocking activity, so response logic lives outside the rule.

Before you commit, confirm with the Falco documentation which output channels your deployment model supports and how your SIEM will ingest the JSON events.

Each option in brief, with its license and governance

Is Falco free to self-host and what license does it use?

Falco is licensed under Apache-2.0, so you can run it in your own clusters without a license fee for the open-source project. Created by Sysdig, its first commit was made in 2016, and it became a CNCF Graduated project on February 29, 2024. The latest release supplied for this page is 0.45.1, published on October 19, 2026. Check the Falco releases page before you plan an upgrade, since the version you deploy will set which driver and plugin behavior you test. Your costs will come from the people who write and tune rules, the time to route alerts into your existing tools, and any support contract you choose to buy from a vendor.

Who maintains Tetragon and is it still actively released?

Tetragon is licensed under Apache-2.0 and is a Cilium project in the cilium/tetragon repository. The latest release supplied for this page is 1.7.1, published on August 25, 2026. Governance sits with the Cilium community, so you should review the project's contributor activity, maintainer list and governance documents yourself before you commit. Because Tetragon is tied to the Cilium ecosystem, confirm how its release cadence fits the Cilium and kernel versions in your clusters. Your ongoing effort includes reviewing each release for changes to tracing policies and kernel compatibility.

Is Tracee still maintained, given its latest supplied release date?

Tracee is an Aqua Security open source project licensed under Apache-2.0. The latest release supplied for this page is 0.24.1, published on November 19, 2025, which is older than the release dates supplied for Falco and Tetragon. That gap does not prove the project is abandoned, but it means you should check current commit activity, open issues and the releases page before you select it. Confirm with Aqua Security or the project maintainers which version they recommend for your kernel and Kubernetes versions. Plan for a short evaluation of recent builds before any production rollout.

What should I verify about KubeArmor before choosing it?

KubeArmor is a fourth option in this comparison, but this page does not include detailed researched facts about it. Before you consider it, confirm its license terms directly in its repository, identify the organization and maintainers behind it, and review the date and frequency of its recent releases. Also check whether its enforcement model matches your requirement, since in-kernel blocking and alert-only detection lead to different operating plans. Ask for a short proof of concept in a non-production cluster so your team can test its policies against the workloads you actually run.

Which of these projects has the clearest governance structure?

Falco has the most documented governance path among the three supplied options, because it was created by Sysdig and later became a CNCF Graduated project on February 29, 2024. Tetragon is maintained within the Cilium project, and Tracee is an Aqua Security open source project. Each has an Apache-2.0 license, so the license alone does not separate them. Governance matters most if you need a neutral foundation, a vendor roadmap or a community that will absorb maintenance if one company changes direction. Review each project's governance documents and contributor history before you decide, and ask whether your organization needs that neutrality in writing.

Who pays for running these tools after the initial setup?

The open-source licenses on all three options carry no license fee, so the recurring cost is staff time and infrastructure. Your team pays for writing and tuning rules or policies, monitoring agent resource use on nodes, upgrading the tool alongside Kubernetes and kernel changes, and routing alerts into a SIEM or ticketing system. If you buy a support contract or a managed service from a vendor, that fee recurs. DeployOpen can plan, implement, customize, harden and document these deployments in your own clusters under a fixed-scope written agreement, and offers ongoing support and upgrades as retainers. When requesting a quote, ask for the scope of rule tuning, upgrade testing and alert integration.

What the Apache-2.0 licenses and project governance mean for you

All three tools are licensed under Apache-2.0, which the Open Source Initiative approves, so license is not what separates Falco, Tetragon and Tracee. You can run, modify and redistribute any of them inside your own clusters without a license fee. The governance behind each project matters more for a multi-year runtime security control. Falco is a CNCF graduated project, with graduation announced on February 29, 2024, which gives it a neutral foundation and a documented governance process. Tetragon is maintained within the Cilium project, and Tracee is an Aqua Security open source project. Ask whether the Cilium project's governance applies to Tetragon in the same way, and whether Aqua Security's commitment to Tracee is funded by a commercial product line that could change its priorities.

Check release cadence and maintainer diversity before you standardize. The supplied release facts show Falco 0.45.1 on October 19, 2026, Tetragon 1.7.1 on August 25, 2026, and Tracee 0.24.1 on November 19, 2025, so the most recent Tracee release is noticeably older than the other two. Look at the release history on each GitHub releases page, how many maintainers commit regularly outside a single company, and how long security fixes take to ship. A project with one active vendor maintainer carries a different continuity risk from one with a broad contributor base.

None of the supplied facts describes a paid edition, enterprise feature set or commercial support contract for Falco, Tetragon or Tracee, so do not assume one exists. Ask each vendor or project sponsor directly whether a commercial support agreement, a long-term support branch, a security advisory channel and an SLA are available, and whether any enterprise features sit outside the Apache-2.0 code. Put the answers in writing. If you need vendor support, that answer decides the platform more than the license text does.

How to choose and pilot a runtime security tool

This sequence turns the Falco, Tetragon and Tracee comparison into a documented decision, so the team knows which enforcement model it needs, whether its nodes can run the tool, and how the tool behaves before it reaches production.

Define the enforcement requirement first
The platform or security lead writes down whether the team needs detection and alerting only, or in-kernel blocking of specific behavior. Falco's documentation describes detection and alerting with forwarding to other components for action, while Tetragon can filter, block and react directly in the kernel. Done means a short written requirement that names the workloads in scope, the actions that must be prevented, and which team responds to alerts.
Confirm kernel and eBPF support on node images
The cluster or platform engineering team checks the kernel version, BTF availability and eBPF permissions on each node image in use, including managed node pools and any hardened or air-gapped images. Falco offers a modern eBPF probe used by default and a kernel module, and Tetragon and Tracee both depend on eBPF. Done means a compatibility record per node image, with the driver or probe each candidate would use, confirmed against each vendor's current documentation rather than assumed.
Pilot one tool in a non-production cluster
The team installs a single candidate in a non-production cluster that mirrors production node images and workload types, and runs it under realistic application load for the period it has agreed internally. Pilot only one tool at a time so that noise and resource use can be attributed correctly. Done means a running install, documented privileges granted to the agent, and a list of any node or workload problems observed.
Measure alert volume and policy noise
The security engineers run the chosen tool's default rules or policies against normal workload behavior and record how many events each rule produces per workload. They then tune rules or TracingPolicy scopes until the remaining alerts are ones a responder would act on. Tetragon's documentation warns that writing tracing policies needs kernel and container knowledge, so reviewers should check each policy with someone who has that background. Done means a tuned rule set, a count of alerts per workload before and after tuning, and a named owner for each rule.
Test enforcement actions in isolation
If the requirement includes blocking, the team applies the enforcement policy only to a disposable test workload and confirms that the action fires as intended and does not disrupt the cluster's own system processes. Testing should cover the exact behavior the policy targets, using an approved test case. Done means a recorded test with the policy version, the test steps, and the observed result, plus a rollback procedure that has been run once.
Verify SIEM integration and event fields
The monitoring team sends the pilot's events to the SIEM or log platform already in use and checks that the fields needed for investigation arrive intact, such as namespace, pod, process lineage and rule name. Falcosidekick can forward Falco events to many destinations, and Wazuh publishes a Falco integration that reads JSON events from a file. Done means sample events visible in the SIEM, a field mapping document, and confirmation of any extra connector or agent that the chosen path requires.
Check governance and release activity
Before a decision, the platform lead reviews the project's license text, maintainer model, release cadence and open security issues on the official repository, and records how the team would receive future versions. This matters because the tool will run privileged on every node and must be upgraded alongside the kernel and cluster. Done means a dated record of the license, the latest release shown on the project's releases page, and the upgrade path the team has agreed for its own environment.

What running Kubernetes runtime security actually costs and requires

Is Falco, Tetragon or Tracee free to run in production?

All three projects are open source under Apache-2.0, so there is no license fee for the software itself. The cost comes from the people and infrastructure around it: engineers who write and tune rules or policies, testing on each kernel and node image you run, a place to send and review alerts, and time for upgrades. Falco and Tracee are typically run with a community or vendor-neutral setup, while Tetragon is delivered through the Cilium project, so confirm with your platform team which distribution and support path fits your clusters. Ask any implementation partner for a written quote that separates one-time build work from recurring tuning and upgrade work.

Can our own platform team run Kubernetes runtime security without outside help?

Often yes for Falco, which is built around detection rules that alert on abnormal behavior and forward events to other tools. Tetragon is harder to run without help. Its documentation warns that writing tracing policies requires knowledge of the Linux kernel and containers to avoid issues such as TOCTOU bugs, and its policies can act inside the kernel, so a mistake can block legitimate workloads. Tracee sits between the two: it monitors system calls, network activity and file operations with eBPF and offers a rule-based policy model. A practical test is whether your team can explain kernel hooks, namespaces and pod identity well enough to review a policy before it reaches production.

What makes the effort to run Kubernetes runtime security grow?

Three factors drive most of the effort. Policy complexity matters most: a few rules that alert on shell execution in containers are far cheaper to maintain than per-workload enforcement policies that filter kernel function arguments. Alert volume matters next, because noisy rules create triage work that repeats every day. The number of clusters and node pools adds kernel and distribution testing, since eBPF behavior and driver support vary by host. Illustrative example: a team with one staging cluster and a short rule set will spend far less time tuning than a team with many production clusters and enforcement policies across several kernel versions.

How much effort goes into integrating runtime alerts with a SIEM?

Integration is usually a separate line item from the runtime tool itself. Falco delivers alerts to standard output, a file, syslog, a spawned program or an HTTP(S) endpoint, and Falcosidekick forwards events to many applications and channels. Wazuh publishes an integration in which Falco on a K3s cluster writes JSON events to a file that a Wazuh agent reads, so Wazuh rules can alert on them. Tetragon and Tracee also produce structured events that need mapping, normalization and retention decisions before a SIEM can use them well. Ask for the event schema, the destinations, the mapping work and who owns the alert queue after go-live.

Does Falco, Tetragon or Tracee block attacks, and what does that change in cost?

Falco's documentation describes detection and alerting, with alerts forwarded to other components to take action, and does not describe Falco itself blocking activity. Tetragon can filter, block and react to events directly in the kernel, for example killing a process when its privileges change before it completes the system call. Tracee is primarily a detection and forensics tool. Enforcement raises the cost: you need stronger testing before rollout, staged policy modes, a rollback plan and on-call coverage for false positives that stop production work. Confirm in writing whether the scope includes enforcement policies or only detection rules.

What does ongoing upgrade and maintenance work look like for runtime security?

Recurring work includes tracking new releases, testing drivers and policies against each Kubernetes and node image, and rebuilding packages after OS updates. The projects release at different cadences. Falco 0.45.1 was published on October 19, 2026, Tetragon 1.7.1 on August 25, 2026, and Tracee's latest release on the GitHub releases page is 0.24.1, published on November 19, 2025. Those dates show that maintenance activity differs by project, so check the releases page before you commit to a support plan. Ongoing support, upgrades and continuous testing can be contracted as retainers, and the retainer scope should name the clusters, the rule or policy sets and the test environments it covers.

What should a quote for Kubernetes runtime security include?

A useful quote states the scope in writing before work starts. Ask for these parts:

The clusters, distributions and node operating systems in scope, with kernel versions
The tool or tools selected, the driver mode and whether enforcement is included
The number and type of rules or policies to be written, reviewed and tuned
The SIEM or alert destinations, event mapping and the alert triage process
Test environments, kernel compatibility testing and rollback steps
Documentation, handover, and a retainer scope for upgrades and continuous testing

DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted platforms inside your own infrastructure, and most engagements are fixed-scope with deliverables and timelines agreed in writing before work starts. DeployOpen does not publish a price list, so a quote follows from the written scope.

Which Kubernetes runtime security tool needs the least effort to start?

The answer depends on the detection goal and your team's kernel skills. Falco usually has the gentlest starting point for alerting, because its custom rules describe abnormal behavior and it can send alerts to many destinations, and it is a CNCF graduated project, graduated on February 29, 2024. Tetragon suits teams that need in-kernel filtering and Kubernetes-aware identity, but it asks for more kernel and container knowledge. Tracee suits teams that want eBPF-based monitoring with Prometheus metrics and forensics-oriented events. Confirm in a pilot cluster how much tuning each one needs against your own workloads before you choose.

Risks to plan for before rollout

Falco, Tetragon and Tracee all depend on kernel-level visibility, and each one can produce noise or disruption if it is rolled out without planning. The cards below cover the risks that cut across the three tools, with the mitigation to plan for each before a cluster is touched.

Kernel driver and node image drift

Falco's default modern eBPF probe, its kernel module alternative, and Tetragon and Tracee's eBPF programs all depend on the kernel of each node. Node pools built from different images, or nodes that receive kernel updates on different schedules, can behave differently under the same policy. Before rollout, inventory kernel versions and node images across every pool, test the chosen driver or eBPF path on each one, and document which combinations are unsupported so that a node image change triggers a re-test.

Alert noise and alert fatigue

Detection rules that fire on normal workload behavior, such as package managers, health checks or batch jobs, will bury real findings. Falco rules are custom and tuned per environment, and Tracee and Tetragon policies have the same tuning burden. Plan a baseline period in a non-production cluster, record which rules fire on expected activity, and set an owner who approves every exception with a reason and an expiry date.

Enforcement that breaks workloads

Tetragon can act on events inside the kernel, for example by killing a process when its privileges change, and the documentation describes filtering and reacting before the system call completes. A policy that blocks a legitimate sidecar, init container or node agent can take down a service. Start every enforcement policy in observe-only mode, promote one rule at a time to enforcement, and keep a tested rollback path that removes the TracingPolicy quickly.

TOCTOU and kernel-level policy pitfalls

The Tetragon documentation warns that writing tracing policies requires knowledge of the Linux kernel and containers to avoid issues such as TOCTOU bugs, where the checked data can change between the check and the use. A policy that inspects arguments at one point may miss what the kernel actually acts on. Assign policy authors with kernel and container knowledge, review each TracingPolicy against the kprobe or tracepoint it hooks, and test policies with known-bad samples before enforcement.

Audit and cloud log data handling

Falco plugins can read Kubernetes audit logs, AWS CloudTrail and Okta, which means the runtime tool will hold records that include user identities, API calls and account activity. Those records may fall under your data protection and retention rules. Before enabling a plugin, confirm where events are stored, who can read them, how long they are kept, and whether forwarding through Falcosidekick or a file output sends them to a system with a different access boundary.

Upgrade cadence across three projects

Falco, Tetragon and Tracee each ship on their own release schedule, and the supplied release facts show different recent versions, including Falco 0.45.1 and Tetragon 1.7.1. Running more than one tool multiplies the testing for kernel compatibility, rule changes and policy syntax. Set a written upgrade policy that pins versions per cluster, tests each release in staging against the node images in use, and names who signs off before production changes.

Where runtime security fits next to host and log monitoring

Kubernetes runtime tools such as Falco, Tetragon and Tracee watch what workloads do inside the kernel, but they do not replace a host intrusion detection system or a SIEM. The practical question is where each signal lands. A runtime tool produces events about process, file and network activity on nodes and pods. Those events need a place to be correlated with authentication logs, host integrity data and alerts from the rest of the estate. Before you pick a runtime tool, map which team will own its alerts and which system will store and triage them.

The documented example to study is the Wazuh integration with Falco. In that setup, Falco runs on a K3s cluster with the modern eBPF driver and writes JSON events to a file, and a Wazuh agent reads that file so Wazuh rules can alert on them. The pattern is useful because it shows the handoff: Falco detects, Wazuh correlates and alerts. Confirm with your platform team whether your node operating system and kernel support the modern eBPF driver, and whether the agent has read access to the output file. If your cluster is not K3s, confirm the file path, log rotation and agent permissions in your own environment before relying on this pattern. Falco's own documentation describes alerts being forwarded to other components to act on, so plan that forwarding path explicitly.

For full monitoring, treat runtime security as one input. Tetragon is the option where enforcement happens in the kernel, so if you need blocking rather than alerting, its policy model and its documentation on kernel-level reaction belong in your review, along with the warning that tracing policies require kernel and container knowledge. For host-level coverage and central log analysis, read the sibling comparisons of open-source host intrusion prevention and open-source SIEM platforms before deciding which platform receives runtime alerts.

How DeployOpen scopes Kubernetes runtime security work

DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside the client's own clusters and cloud accounts. For Kubernetes runtime security, that means choosing and deploying the detection or enforcement tool that fits your cluster, rule set and alert workflow, then testing and handing over the result in your environment.

How we scope

Start by confirming cluster distributions, kernel versions and whether nodes allow the eBPF driver each tool needs.
Agree in writing whether the goal is alerting only, in-kernel enforcement, or both, since the tools differ on this.
Define which event sources, such as Kubernetes audit logs or cloud trails, feed the detections and where alerts must land.

How we build

Deploy the chosen runtime tool with its rules or tracing policies, scoped to the namespaces and workloads in the agreed scope.
Connect alert outputs to your SIEM or alerting path, for example by forwarding JSON events to an existing agent or receiver.
Test detections against agreed attack scenarios and tune rules to reduce noise before anything is treated as production-ready.

How we hand over

Document the architecture, driver choice, rule or policy inventory, and the upgrade path for each component in the scope.
Provide runbooks for triaging alerts, changing tracing policies safely and rolling back a policy that disrupts workloads.
Walk your platform and security teams through the deliverables so they can operate the stack without DeployOpen on call.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer, scoped separately from the original engagement.
Ask for the retainer scope in writing, including which tool versions are covered and how kernel or Kubernetes upgrades are handled.
Confirm your internal ownership of rule changes, since policy tuning drives most of the long-term effort in runtime security.

Open-source Kubernetes runtime security compared