Vision

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:

Strong Identity & Authentication
Every user, every device, every service must prove who they are. Credentials, device posture, attestation, identity signals: these are continuously evaluated.
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.
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.
Continuous Verification / Context Awareness
Trust decisions are not static. They consider context: device health, recent behavior, time, location, the system’s state.
Monitoring, Auditing, Feedback, and Automation
You need visibility into what is going on (flows, anomalies), to enforce policy, and to adjust dynamically.
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:

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?

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)

Layer	What It Covers	Trust / Identity / Controls
Kernel / Process Attestation	Code origin, integrity, execution environment	SPIFFE IDs issued only after attestation; no userspace code is trusted by default
Inter-process / Service Communication	Workload → workload, on same host or across hosts	mTLS with SPIFFE IDs, policy enforcement per identity
Node / Host	The host’s posture, environment, security properties	Host attestation, secure boot, minimal trusted host invariants
Data Center / Cloud	Networking, segmentation, environment boundaries	Trust federated via identity, policies enforce cross-workload access
Multi-Cloud / Hybrid / Cross-Partner	Heterogeneous environments, partners, external workloads	Identity federation, on-demand credentials, consistent identity model across boundaries

Conclusion

Zero trust isn’t a product you buy; it’s a mindset, a set of architectural commitments. From Kindervag’s early formulation through Google’s BeyondCorp/BeyondProd, Cloudflare’s identity-based enforcement, we’ve seen how zero trust can dramatically reduce risk, but also how most implementations still assume some level of implicit trust and/or static credentials.

At Riptides, we push the boundary further: **kernel first:**trust nothing in userspace without attestation; only then issue identity; only then allow communication, based on fine-grained policy; extending trust across clouds via federation and credential injection. This gives us: stronger guarantees, smaller blast radius, and more defensible, resilient infrastructure. If you’re building systems today, especially cloud-native, distributed, hybrid or multi-cloud, it’s no longer sufficient to trust by node or network zone. The kernel is where the implicit trust still lingers — remove it, and you’re in a much stronger security posture.

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.

vision spiffe identity zero-trust kernel linux