Riptides adds mTLS to Kubernetes without a service mesh. Mutual TLS enforced at the kernel, with no Istio, no Linkerd, no sidecar proxies, and no application changes.
Istio and Linkerd work. They also add sidecar proxies to every pod, require dedicated platform teams to operate, introduce latency, and create a new failure domain for your cluster. Most teams end up with partial coverage, the services they got around to configuring, rather than universal enforcement.
Each sidecar adds memory, CPU, and startup latency. In large clusters, the aggregate overhead is significant, and you're running infrastructure to secure infrastructure.
Service meshes require a certificate authority, rotation policy, and trust hierarchy. cert-manager helps, but every component adds operational surface that can break during incidents.
Sidecar proxies operate at the application layer. A compromised workload can communicate directly with the network stack, bypassing proxy-level policy entirely.
mTLS requires services to be part of the mesh. Legacy workloads, batch jobs, and anything not using the mesh sidecar are excluded, leaving gaps in your encryption posture.
A Linux kernel module on each node intercepts all outbound connections, attaches a SPIFFE identity to the workload making the call, and enforces mTLS before the packet leaves the host. No sidecar, no proxy, no config change in your application.
Every pod, container, and process gets a SPIFFE SVID at startup, automatically, based on what it is and where it runs. No annotation, no init container.
The kernel module intercepts outbound connections before they hit the network. It attaches the workload's SVID and negotiates mTLS, transparently, below the application.
Both sides of every connection present their SPIFFE identity. Connections from workloads without a valid identity are rejected at the kernel level.
Short-lived certificates are issued and rotated automatically. No cert-manager configuration, no renewal runbooks, no risk of expiry-related outages.
Yes. Riptides enforces mTLS at the Linux kernel level, below the application and network layer. Every Kubernetes service gets mutual TLS without installing Istio, Linkerd, or any sidecar proxy. The kernel module intercepts connections and handles certificate negotiation transparently before packets leave the host.
Service meshes like Istio and Linkerd add sidecar proxies to every pod to enforce mTLS at the application layer. This works but adds memory and CPU overhead, requires dedicated operational effort, and can be bypassed by a compromised workload that communicates directly with the network stack. Riptides enforces mTLS at the Linux kernel, which cannot be disabled or bypassed from within the application, and requires no sidecar, no proxy, and no configuration changes.
Yes. The Riptides kernel module is deployed as a DaemonSet on each node and automatically covers all workloads running on that node. No annotation, no sidecar injection, no application change is required. Existing services begin getting SPIFFE identity and mTLS immediately after the module is deployed.
If the module is removed, workloads continue running without mTLS enforcement. There is no cascading failure or downtime. Riptides is designed for incremental adoption, so you can start with one cluster, one namespace, or one service and expand at your own pace.
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.