longhorn

What is Longhorn?

The Longhorn image packages Rancher's open-source distributed storage system so you can provide reliable persistent volumes to Kubernetes workloads without managing an external storage backend. Longhorn runs entirely inside your Kubernetes cluster — each node contributes local disk to a shared storage pool, and Longhorn handles replication, scheduling, and volume lifecycle via its own controller and engine processes. It supports incremental snapshots, scheduled backups to S3-compatible object storage, and cross-cluster volume migration, making it a popular choice for teams running stateful workloads like databases, message queues, and ML model registries on self-managed or edge Kubernetes clusters where cloud-native storage primitives aren't available.

What is Echo's Longhorn image?

Echo's Longhorn image is a hardened build of Longhorn on Echo's hardened base. Echo images are designed to be a drop-in replacement: change the FROM line in your Dockerfile and CVEs go to zero without breaking your persistent storage layer. Every image is tested across clouds, image use cases, and deployment targets. Echo ships every image in two variants: a distroless variant optimized for runtime use, and a default variant that includes essential build tools, package managers, and shells. For production storage deployments, the distroless variant minimizes attack surface while keeping volume replication, snapshot scheduling, and backup behavior fully intact; the default variant suits platform teams that need shell access for storage diagnostics, volume inspection, or operational tooling.

What is the difference between Echo's Longhorn image and the public Longhorn image?

Public Longhorn images ship on bases that include OS-level tooling convenient for storage operations but which contribute CVEs that accumulate on a component running persistently across every node in your cluster. A vulnerable storage layer is particularly high-stakes — it sits beneath your databases, message queues, and any other stateful workloads, meaning a compromised storage component can affect everything above it. Echo's build retains everything Longhorn needs for volume management, replication, and backup while removing the packages that don't belong in a production storage container. As we covered in our post on securing Docker images, the base image choices for persistent infrastructure components are often made once and left unchanged for months — making a clean starting point essential. Echo commits to a 7-day SLA for critical and high severity vulnerabilities, and 10 days for medium, low, and unknown — with vulnerabilities triaged within 24 hours. Echo images are recognized by all major scanners and mirrored to all major registries, so they fit into existing pipelines without changing your registry, scanner, or runtime tooling.

FAQ

Can I replace my Longhorn image with Echo's Longhorn image?

Yes. Echo's Longhorn image is a drop-in replacement. Update the image reference in your Helm chart or Longhorn manifests and your storage layer keeps running — the CVEs disappear, the behavior doesn't. Volume replication, snapshot scheduling, backup to object storage, and the Longhorn UI all continue to work without any changes to your existing storage configuration or volume topology.

Is Echo's Longhorn image FIPS-validated?

Yes. Echo's FIPS-validated images use cryptographic modules with an active FIPS 140-3 CMVP certificate, making them fit for federal use — unlike FIPS-compliant images that haven't been validated. This matters for teams running stateful workloads inside FedRAMP boundaries where the storage layer handling encrypted data must itself meet cryptographic requirements.

What is Echo's vulnerability management SLA on the Longhorn image?

Echo commits to a 7-day SLA for critical and high severity vulnerabilities, and 10 days for medium, low, and unknown — with vulnerabilities triaged within 24 hours. Patches are mirrored automatically into your private registry so you're always running a clean version — critical for a storage component that runs continuously across every node and is rarely cycled in production.

Is Echo's Longhorn image distroless?

Echo ships every image in two variants: a distroless variant optimized for runtime use, and a default variant that includes essential build tools, package managers, and shells. For production storage deployments, the distroless variant is the leaner, more secure choice; for platform teams that rely on shell access for volume diagnostics, storage inspection, or backup verification workflows, the default variant is the right fit.

How does Echo achieve such a drastic CVE reduction in Longhorn?

Echo's Longhorn image is built from source with only the absolute essentials needed to run the distributed storage workload, which significantly shrinks the attack surface. Echo also patches aggressively over time, with backports available so you can stay on the Longhorn version that works for your storage architecture without forcing a functional change for the sake of security.

Will Echo's Longhorn image help us achieve FedRAMP?

Yes. The hard parts of FedRAMP — managing vulnerabilities, applying fixes, and using FIPS-validated cryptography — are baked into Echo images, including STIG-hardened configuration and ConMon/POA&M-ready reporting. For platform teams running stateful Kubernetes workloads under an ATO, Echo's hardened Longhorn image keeps the persistent storage layer in-boundary and compliant.