Zero Trust: From Perimeter to Kernel - How Riptides Pushes the Boundary

In the evolving threat landscape, “zero trust” is hardly a new phrase - but it is more important than ever. As attackers become more sophisticated, identity-based, lateral movement, and subtle persistence-based threats are no longer edge cases; they’re part of the assumed baseline. This post will walk through the general principles of zero trust (drawing on sources like John Kindervag’s original model, Google’s BeyondCorp/BeyondProd, Cloudflare’s implementation), then introduce how Riptides takes zero trust further, from the perimeter, to the node, to the kernel and why that matters for modern infrastructure security.

TL;DR: We achieve this kernel-level zero trust using strong attestation, SPIFFE for strong workload identity and kTLS for secure, identity-bound communication.

The General Principles of Zero Trust

Let’s begin with what zero trust means in practice, drawing from the original “never trust, always verify” model and how major players have implemented it.

Origins: Kindervag & the “Perimeter is Dead”

• John Kindervag (Forrester analyst) popularized zero trust ~15 years ago, criticizing traditional perimeter-based defenses that implicitly trust everything inside a firewall. The idea: just because traffic is “inside” doesn’t mean it should be trusted.
• The core mantra: Assume breach. Trust nothing by default. Reduce the blast radius of any intrusion. Enforce strong segmentation, least privilege, continuous verification.

Key Concepts (as distilled over time)

Established guidance from Kindervag, NIST, and Google shows that robust zero trust architectures typically include:

1. Strong Identity & Authentication
   Every user, every device, every service must prove who they are. Credentials, device posture, attestation, identity signals: these are continuously evaluated.
2. Least Privilege Access / Principle of Minimal Privilege
   Access granted only to what is needed, for as long as it is needed. Permissions are narrowly scoped, ephemeral where possible.
3. Micro-Segmentation
   Even within the data center or network, break up the environment so that lateral movement is constrained. Each boundary (service-to-service, process to process) is guarded.
4. Continuous Verification / Context Awareness
   Trust decisions are not static. They consider context: device health, recent behavior, time, location, the system’s state.
5. Monitoring, Auditing, Feedback, and Automation
   You need visibility into what is going on (flows, anomalies), to enforce policy, and to adjust dynamically.
6. No Implicit or Perimeter Trust
   Simply being “inside” a network doesn’t confer trust. All traffic (east-west, north-south), all processes, all workloads must be verified.

Perspectives: Google BeyondCorp / BeyondProd & Cloudflare

Google’s BeyondCorp & BeyondProd

• BeyondCorp is Google’s internal zero trust model for user access: decoupling trust from network location. Whether you’re in the office or remote, access is granted based on identity, device posture, and context.
• BeyondProd extends those ideas into production / services: no service is assumed to trust any other by default; workloads run on trusted machines, code provenance is verified; internal services enforce mutual distrust unless explicitly authorized.

Cloudflare’s Zero Trust & “Access”

• Cloudflare has built zero trust features into its access product: e.g., Cloudflare Access allows enforcing identity / device posture / location / additional signals before letting users reach applications.
• They also apply zero trust to SaaS applications (not just internal apps) by aggregating identity signals, enforcing rules based on multiple criteria, generating JWTs, etc.
• Their model emphasizes shifting checks away from assuming trust at the network boundary and instead making access decisions earlier, with many signals.

The Riptides Narrative: Zero Trust at the Kernel

‍

From Perimeter → Node → Kernel

Many zero trust implementations focus on either:

• securing the perimeter (user access, VPN replacement, access proxies)
• or focusing on the node / workload (services talking to other services, microservice authentication, service mesh levels)

At Riptides, we believe zero trust should start even deeper: at the kernel.

• We adopt a posture of default distrust: nothing in userspace is trusted by default. Every workload, every process, every piece of code that runs in userspace must undergo attestation.
• We leverage SPIFFE (Secure Production Identity Framework for Everyone) for workload identity, issuing cryptographic identities (SVIDs) to workloads only after attestation. If a process doesn’t have a trusted identity (SPIFFE id), it’s not implicitly trusted.

So: for Riptides, it’s not enough that “access came from a trusted host” — the code itself, its provenance, its execution context, its behavior must be verified, attested, and assigned identity. That identity becomes the basis for further trust decisions.

Getting Trust Once Identity is Established

Once a workload/process has passed attestation and obtained a SPIFFE identity (an SVID), that becomes the key to building more complex trust relationships:

• Within a data center: workloads can verify each other via SPIFFE mutual TLS (mTLS), with fine-grained policies based on SPIFFE IDs.
• Across clouds: we support workload identity federation and on-demand credential injection to enable trust among workloads running in heterogeneous environments.
• Trust expansion is governed by policy: e.g. “this SPIFFE identity (workload/service/process A) can talk to workload/service/process B under certain conditions”, always under least privilege, and policy based.

To dive deeper into how we handle workload identity federation and on-demand credential injection, take a look at these posts:

• Federating non-human identities with external IdPs using ID tokens in AWS, GCP, and Azure
• Why Cloud-Native Federation Isn’t Enough for Non-Human Identities in AWS, GCP, and Azure
• Introducing libsigv4: AWS SigV4 Signatures in Portable C with Kernel Compatibility
• On-the-Wire Credential Injection: Secretless AWS Bedrock Access example
• On demand credentials - Secretless AI assistant example on GCP
• Workload Identity Without Secrets: a Blueprint for the Post-Credential Era
• Introducing tokenex: an open source Go library for fetching and refreshing cloud credentials

Why Starting in the Kernel Matters

• Reduces “implicit trust” risks: Even trusted nodes / hosts can be compromised. Attackers may use privilege escalation or code injection. By enforcing that userspace code itself must be verified, you shrink the attack surface.
• Better granularity: Trust decisions are made not just at the host boundary, but per process, per workload. Lateral movement and privilege escalation are harder.
• Uniform identity basis: Using a standard like SPIFFE means consistency: policies are uniform, identities portable, credential issuance / revocation more manageable.
• Cross-environment and cross-cloud coherence: As organizations use hybrid/multi-cloud, having a kernel-based identity/attestation basis helps ensure that trust is meaningful across environments.

Interested in how our Linux kernel journey unfolded and what we learned along the way?

• Rethinking Workload Identity at the Kernel Level
• 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

How Riptides Realizes This in Practice

• SPIFFE + Attestation
  Every process/workload must undergo attestation (code origin, execution environment, etc) before being issued an SVID in kernelspace. No unverified userspace process is trusted.
• Mutual TLS & Policy Based on SPIFFE IDs
  Once workloads have identities, communications between them are authenticated via mTLS using those identities. Policy engines decide what identities can communicate or access which services.
• Workload Identity Federation
  For workloads outside our control, we support identity federation so they can present acceptable identities to integrate with our system. This allows cross-cloud trust without resorting to static credentials or VPNs.
• On-Demand Credential Injection
  Instead of embedding long-lived secrets in workloads, credentials are injected in kernelspace only when needed, tied to identity, and revoked when no longer valid.
• Continuous Monitoring and Policy Enforcement
  Even after identity issuance, processes and workloads are monitored and re-attested. If a process becomes non-compliant, its trust is revoked or restricted.

Putting It All Together: The Riptides Zero Trust Stack (Kernel-First)