No SDK. No sidecar. No proxy. A Linux kernel module that secures every workload on the node — any language, any framework, no code changes.
Your team adopted a service mesh for mTLS. Now you spend two days a week on mesh configuration tickets. Sidecars consume 30% of your cluster CPU. When one crashes, the workload goes dark and you're debugging Envoy at 2am. The tool you deployed for security has become the thing that pages you most.
Every pod runs an Envoy proxy. If the sidecar crashes, the workload loses connectivity. Your security layer is your availability risk.
CPU, memory, and an additional network hop on every request. At scale, sidecar overhead rivals the workloads they protect.
Each language needs its own security SDK — Python, Go, Java, Node.js, Rust — each with its own configuration, upgrade cycle, and on-call runbook.
eBPF programs are sandboxed by design. They cannot generate private keys, perform TLS handshakes, inject credentials, or enforce access policy. Visibility without enforcement is a dashboard, not security.
Riptides deploys as a kernel module on each node. It handles identity, encryption, credential injection, and policy enforcement — transparently, for every process on the node. No sidecars, no SDKs, no per-app configuration.
On Kubernetes: a DaemonSet with a driver-loader init container. On bare metal or VMs: a .deb/.rpm package and a systemd service. Two components, one deployment.
The module handles mTLS, credential injection, and access policy enforcement for every process on the node. Applications are completely unaware — no code changes, no configuration per workload.
The agent connects to the control plane and pushes identity policies, certificates, and credential bindings to the kernel module. Changes take effect immediately — no workload restarts.
Each node runs its own independent kernel module. A failure on one node does not affect any other node. Not a cluster-wide event.
If the module is unloaded, workloads revert to normal TCP behavior. The security layer degrades gracefully; workloads don't go dark.
Kernel module updates follow the same DaemonSet rolling update strategy you use for everything else. Node by node, with health checks between.
Start with PERMISSIVE — accepts both plaintext and mTLS. Monitor telemetry. Enforce when ready. No big bang cutover.
Deploy Riptides on one cluster running a service mesh. Start in permissive mode — existing sidecar mTLS continues to work alongside kernel-level mTLS. Validate with telemetry, then remove the sidecars. One kernel module per node replaces hundreds of sidecar proxies.
On why kernel-level enforcement changes the security model for workload identity, and why code-level approaches fall short: Rethinking Workload Identity at the Kernel Level →
Zero-touch workload security means every workload running on a node is automatically enrolled in identity, policy enforcement, and encrypted connections without any annotation, sidecar injection, SDK import, or application configuration. The security layer is applied transparently at the kernel level, below the application entirely. It is distinct from zero-touch device provisioning (bootstrapping IoT or edge hardware) -- it refers specifically to runtime security controls applied transparently at the kernel level, covering any language and any framework without source code access.
Sidecar-based security (service meshes like Istio and Linkerd) injects a proxy container alongside each application pod. The proxy intercepts traffic and enforces mTLS and policy at the application layer. This requires every pod to be annotated, every namespace to be mesh-enabled, and every sidecar to stay healthy. When a sidecar crashes, the workload loses connectivity. At scale, sidecar CPU and memory overhead rivals the workloads they protect.
Zero-touch workload security moves that enforcement into the Linux kernel module, deployed once per node. There are no per-pod proxies, no annotations, no per-workload configuration. Every process on the node is covered automatically from the moment the module loads. Upgrades happen via a DaemonSet rolling update rather than restarting individual application pods.
Zero-touch means the Riptides kernel module is deployed once per node as a DaemonSet, and every workload running on that node is automatically covered. No SDK to import, no sidecar to inject, no framework to integrate with, no application code to change. Existing services begin receiving SPIFFE identity and policy enforcement immediately without any modification.
Riptides supports modern Linux kernel versions used in major Kubernetes distributions including EKS, GKE, AKS, and self-managed clusters. Specific version requirements are available in the documentation. The module is built and tested against multiple kernel versions and distributions as part of the Riptides CI/CD pipeline.
Riptides starts in permissive mode by default. In permissive mode, the module observes and logs all connections and policy decisions without blocking anything. You validate the identity map and policy decisions against your expected traffic, then switch to enforce mode for each service at your own pace. There is no big-bang cutover required.
The kernel module intercepts connections at the socket layer and adds the latency of identity lookup and certificate negotiation. For most workloads this is sub-millisecond on the first connection, with session resumption reducing overhead for persistent connections. Specific benchmarks are available on request.
Identity, access control, and a full audit trail for every agent and service — enforced on the host, with no code changes. Up and running in an afternoon.