Every connection authenticated by SPIFFE identity. Kernel-level mutual TLS with no SPIRE daemon, no sidecar, and no cert-manager configuration.
The pen tester got a foothold on one workload and reached the database in three hops. The finding: "Lateral movement unrestricted within network segment. No mutual authentication between services." IP-based security gives you the illusion of segmentation without actual identity.
Two workloads on the same subnet look identical to a firewall. An attacker who compromises one inherits all of its network-level access.
Pod selectors and CIDR blocks don't prove who is connecting — they prove where traffic originates. When a pod moves, the policy may not follow.
Sidecar proxies provide mTLS, but they run in user space. Misconfigured iptables rules let traffic bypass the sidecar. When the sidecar crashes, the workload falls back to plaintext — silently.
Most service-to-service communication uses one-way TLS at best. The server proves its identity; the client does not. Any process that can reach the endpoint is implicitly trusted.
Deploy the Riptides agent. Your workloads get identity automatically — no code changes, no config. Every connection is encrypted and mutually authenticated. Applications send plaintext; the network carries encrypted, authenticated traffic.
Install the agent and enable permissive mode. All existing traffic continues to flow while Riptides maps every connection by identity. No enforcement yet — just attribution.
When both sides have Riptides, connections are automatically encrypted and mutually authenticated. Applications send plaintext; the kernel handles the rest. No code changes, no certificate management.
Control which workloads can talk to each other using identity-based policies — not IP addresses. Only explicitly allowed identities can connect. Switch to enforce when ready.
Standard SPIFFE deployments require a SPIRE Server and a SPIRE Agent running on every node. The SPIRE Agent contacts the SPIRE Server to obtain an SVID for each workload, which means certificate issuance depends on a reachable control plane. Riptides issues SVIDs from inside the kernel module itself, so there is no separate agent process and no registration entry needed per workload.
There is no separate control plane component to deploy, version, or monitor. The Riptides kernel module handles SVID issuance directly, without making an outbound call to a server during connection establishment.
SPIRE requires you to pre-register each workload with a selector before it can receive an SVID. Riptides derives identity from workload attributes at the kernel level automatically, so new workloads get identity without an operator step.
Because certificate negotiation does not depend on a live connection to a SPIRE Server, mTLS keeps working during a control plane restart, a network partition, or a partial outage. There is no fallback to plaintext.
Move from "network segmentation" to "SPIFFE identity on every connection." The pen tester's lateral movement path no longer exists.
Keys are generated and stored exclusively in kernel space. No process, memory dump, or debug tool can extract them.
Connections without a matching policy are blocked before the application sees them. No implicit trust, no fallback to plaintext, no way to bypass from user space.
Start with PERMISSIVE mode — accepts both plaintext and mTLS. Watch every connection map by identity. Switch to MUTUAL to enforce. No cutover weekend.
Two workloads on the same subnet cannot communicate unless explicitly allowed by identity. Lateral movement after breach is contained to the compromised identity — not the network segment.
Database connections and Kafka/RabbitMQ traffic authenticated with mTLS. The database sees a verified identity on every connection — no passwords, no shared certificates.
When combined with identity federation, the same mTLS model extends across clusters, clouds, and organizational boundaries.
| Network-Based Security | Riptides | |
|---|---|---|
| Identity model | IP addresses, CIDR blocks | Cryptographic workload identity |
| Authentication | None (trust the network) | Mutual TLS on every connection |
| Lateral movement | Unrestricted within zone | Blocked unless explicitly allowed |
| Private key protection | Application manages keys | Keys in kernel memory only |
| Enforcement | Sidecar proxy (user-space, bypassable) | Kernel module (cannot bypass) |
| Code changes | Proxy config, iptables rules | None |
| Identity portability | Tied to IP / pod selector | Follows workload across infra |
| Audit posture | "We have network segmentation" | "Every connection is cryptographically authenticated" |
Why sidecar-based mTLS does not fully contain a compromised workload, and why the enforcement boundary matters: The Hidden Risk in Service Mesh mTLS →
Automatic mTLS means every connection between services is mutually authenticated and encrypted without any configuration change in the application code. Riptides intercepts outbound connections at the Linux kernel, negotiates mutual TLS using the workload's SPIFFE SVID, and establishes an encrypted channel. The application is unaware the encryption is happening.
SPIFFE SVIDs are short-lived and auto-rotating. Riptides handles the full lifecycle: issuance at process startup, rotation before expiry, and revocation when a workload stops. Applications never manage certificates, there are no rotation runbooks, and there is no risk of service disruption from an expired certificate.
Yes. Riptides supports SPIFFE identity federation across clusters, clouds, and organizations. A workload in one AWS region can establish a mutually authenticated mTLS connection to a service in GCP using federated trust, without VPNs or shared secrets.
For most teams, yes. Riptides delivers the primary benefit of a service mesh -- encrypted, mutually authenticated service-to-service connections -- without the sidecar proxy, the operational overhead, or the partial coverage that service meshes typically deliver. If you already run a service mesh, Riptides can complement it by adding kernel-level enforcement below the proxy layer.
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.