Rethinking Workload Identity at the Kernel Level

Beyond Sidecars and Proxies: Why the Linux Kernel Is the Future of Non-Human Identity

As SPIFFE (Secure Production Identity Framework for Everyone) solidifies its role as the industry standard for workload identity, the question is no longer whether to adopt it — but how. SPIFFE provides a powerful abstraction for securely identifying workloads using cryptographic SVIDs (SPIFFE Verifiable Identity Documents), but the ways it’s currently deployed often fall short of the operational efficiency, portability, and security guarantees that modern enterprise infrastructure demands.

In today’s distributed, cloud-native world, non-human identity is foundational to Zero Trust architectures. But the way these identities are issued and enforced — especially at scale — matters more than ever. And hiding in plain sight is a simpler, more universal and scalable foundation for workload identity: the Linux kernel.

SPIFFE Today: It Works But at an Operational Cost

Most SPIFFE deployments today fall into one of three patterns, all with real compromises.

1. Application-Level Integration

This method embeds SPIFFE logic directly into workload code via libraries. In theory, it’s flexible. In practice:

• It burdens developers with identity and security decisions that shouldn’t belong in application logic.
• It relies on a limited set of supported languages and libraries.
• It violates the principle of separation of concerns: developers should write business logic, not identity plumbing.

Ultimately, pushing identity into application code turns a universal infrastructure concern into a fragmented implementation detail — fragile, hard to scale, and easy to get wrong.

2. Sidecars and Proxies (Including Service Meshes)

In most modern SPIFFE deployments, identity is handled by an external agent or proxy either injected as a sidecar or embedded in a service mesh proxy like Envoy. These architectures have gained popularity for automating mTLS and simplifying SVID rotation, especially in Kubernetes environments. But they come with real drawbacks:

• Kubernetes-only by default: These models rely heavily on Kubernetes primitives like sidecar injection, making them hard to adopt in VMs, bare metal, or edge deployments.
• Heavyweight and resource-intensive: Every workload gets a proxy process, adding compute, memory, and management overhead across the fleet.
• Indirection breaks identity fidelity: The workload’s identity is no longer directly tied to the process initiating communication, but to a neighboring proxy or agent. This weakens the trust boundary and opens the door to identity confusion or lateral movement.
• Opaque security posture: Policies, credentials, and rotations happen in separate agents. Debugging or verifying behavior often requires understanding multiple moving parts across control and data planes.

Sidecars and service meshes helped SPIFFE gain traction but they are scaffolding, not the foundation. As organizations scale into tens or hundreds of millions of workloads, these externalized identity layers introduce complexity, cost, and architectural drag.

Kubernetes isn’t everywhere. Proxies aren’t everywhere. But the Linux kernel is. Whether your workloads run on VMs, containers, bare metal, or edge nodes, they all ultimately interface with the kernel opening sockets, issuing syscalls, launching processes. So instead of gluing SPIFFE on from the outside, why not issue identities from the inside, at the source of execution itself?

The Riptides Approach: Identity Issued in the Kernel

Riptides issues SPIFFE-compliant SVIDs as ephemeral X.509 certificates directly inside the Linux kernel, binding them to the actual process responsible for initiating communication.

Using kernel TLS (kTLS), we inject those identities directly into the TLS handshake at the record layer not through userspace, not via shared files, not through sidecar mediation. From the first packet, the workload’s identity is embedded, verified, and enforced.

🔍 Dive deeper: Seamless Kernel-Based Non-Human Identity with kTLS and SPIFFE

This model flips the script:

• No code changes: Applications remain unaware of SPIFFE, and that’s the point.
• No sidecars, no proxies: You eliminate architectural bloat and performance tax.
• Works anywhere Linux runs: Kubernetes, VMs, or bare metal, no platform lock-in.
• Strong process binding: Identities are assigned per-process at the syscall level, not per-pod or per-node.
• Zero userspace dependency: Secrets never touch disk or userspace memory. No gRPC APIs. No filesystem mounts.

How It Works: A High-Level Technical Overview

Once Riptides is installed, the system operates transparently and automatically at the kernel level.

1. The Riptides user-space daemon receives SPIFFE identities, trust bundles, and connection policies from the control plane.
2. These are loaded into the kernel riptides-driver via device driver communication.
3. When a TCP connection is initiated, the driver:
   • Checks the destination against policy.
   • Initiates a full mTLS handshake (not just record protection) in the kernel using SPIFFE-based certificates.
   • Establishes a kTLS session for record encryption/decryption.

This design has multiple benefits:

• Security: Secrets never leave kernel memory, reducing exposure.
• Transparency: Applications are unaware they’re speaking mTLS - zero code changes.
• Policy enforcement: Fine-grained identity-based access control happens at connection time.

There are no persistent credentials. Nothing to leak. No proxy to trust. It’s security rooted in the actual workload, at the lowest trustworthy layer.

Kernel Development Is Not for the Faint of Heart

Issuing and enforcing identity in the kernel isn’t just a bold technical decision, it’s what enables Riptides to deliver per-process identity binding, zero credential leakage, and platform-agnostic enforcement but it’s also a non-trivial engineering challenge.

Unlike userspace software, kernel modules must operate across a wide landscape of Linux distributions, kernel versions, and cloud provider variants. Supporting even a small matrix of environments means contending with:

• Version fragmentation: Different distros backport patches and modify kernel interfaces, making compatibility a moving target.
• Debugging complexity: Traditional tooling breaks down in kernel space debugging often requires tracepoints, kprobes, custom logging infrastructure, or full crash analysis.
• Upgrade resilience: Kernel module APIs and ABIs change over time, so staying ahead of updates requires continuous tracking and rigorous regression testing.
• Security scrutiny: Operating inside the kernel means adhering to strict memory safety, syscall hygiene, and sandboxing rules — because any flaw has privileged blast radius.
• Distribution challenges: To ensure wide adoption, kernel modules need to be shipped through the appropriate vendor ecosystems (e.g. Red Hat’s kmod programs, Amazon’s kernel module packaging workflows, or custom drivers for cloud-native runtimes).

These aren’t theoretical hurdles, they’re real-world blockers that have historically limited the adoption of kernel-based solutions, especially for security-critical workloads.

We’ve Done the Hard Work So You Don’t Have To

At Riptides, we’ve built deep kernel expertise from the ground up, not just in developing high-performance, memory-safe modules, but in the tooling, compatibility layers, and distribution channels required to operate reliably across fleets.

• We maintain a continuous integration pipeline that builds and tests our kernel module against dozens of kernel versions, including major distributions and LTS branches.
• Our system integrates with eBPF-based observability and tracepoints, allowing us to diagnose issues and ensure correctness without disrupting workloads.
• We participate in kernel module packaging programs across Red Hat, Amazon, and other cloud providers to ensure seamless, verified distribution.
• And critically: installation and upgrades are automatic and unobtrusive. Riptides deploys as part of your existing provisioning process and silently adapts to the underlying system - no kernel patching, no user intervention.

While kernel development is hard, running Riptides is not. You get all the benefits of syscall-level identity enforcement without having to touch the kernel yourself.

We’ve written extensively about our kernel-level architecture — from tracing and telemetry pipelines to eBPF-based observability and real-time identity enforcement. You can explore more in our #KERNEL blog series:

• Riptides: Kernel-Level Identity and Security Reinvented
• From Breakpoints to Tracepoints: An Introduction to Linux Kernel Tracing
• From Tracepoints to Metrics: A journey from kernel to user-space
• Seamless Kernel-Based Non-Human Identity with kTLS and SPIFFE
• Linux kernel module telemetry: beyond the usual suspects
• From Tracepoints to Prometheus: the journey of a kernel event to observability

A Cleaner, Faster, Safer Future for Non-Human Identity

Non-human identity is too foundational and too sensitive to be bolted on as an afterthought. It deserves a native, first-class treatment.

By operating directly in the Linux kernel, Riptides removes layers of complexity and guesswork, grounding identity in the one place all workloads truly run. No proxies, no sidecars, no credential sprawl just cryptographic trust, bound to the process itself.

The future of identity isn’t just more secure. It’s leaner, simpler, and built in from the start. And with Riptides, it’s already here

---

If you enjoyed this post, follow us on LinkedIn and X for more updates. If you'd like to see Riptides in action, get in touch with us for a demo.