thanos

What is Thanos?

The Thanos image packages the Thanos observability toolkit so you can extend Prometheus with long-term storage and global query capabilities inside containers without managing the underlying infrastructure manually. Thanos works as a sidecar alongside Prometheus, continuously uploading TSDB blocks to object storage, while its Querier, Store Gateway, Compactor, and Ruler components handle global query federation, historical data access, downsampling, and alerting at scale. It is the standard choice for platform and SRE teams that need to retain metrics beyond Prometheus's local retention window, query across multiple Prometheus instances, or build a highly available observability stack without replacing Prometheus entirely.

What is Echo's Thanos image?

Echo's Thanos image is a hardened build of Thanos 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 metrics pipeline. 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 observability deployments, the distroless variant minimizes attack surface while keeping sidecar uploads, query federation, compaction, and store gateway behavior fully intact; the default variant suits platform teams that need shell access for configuration debugging, bucket inspection, or operational tooling around the Thanos CLI.

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

Public Thanos images ship on bases that include OS-level tooling useful for operational tasks but which contribute CVEs that accumulate on components running persistently across your observability stack. Observability infrastructure is a frequently overlooked attack surface — Thanos components run continuously, have access to object storage credentials, and sit at the center of your metrics pipeline, making a vulnerable image a meaningful risk. Echo's build retains everything Thanos needs for sidecar uploads, query federation, compaction, and long-term storage access while removing the packages that don't belong in a production observability container. As we covered in our post on how to protect your company from software supply chain attacks, infrastructure tooling images like Thanos are common blind spots in vulnerability programs precisely because they sit outside the application layer. 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 Thanos image with Echo's Thanos image?

Yes. Echo's Thanos image is a drop-in replacement. Update the FROM line in your Dockerfile or the image reference in your Helm chart and your metrics pipeline keeps running — the CVEs disappear, the behavior doesn't. Sidecar TSDB uploads, Querier federation, Store Gateway access, Compactor downsampling, and Ruler alerting all continue to work without any changes to your existing Thanos configuration or object storage setup.

Is Echo's Thanos 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 platform teams operating observability stacks inside FedRAMP boundaries where Thanos components handling metrics data and object storage credentials must meet cryptographic requirements.

What is Echo's vulnerability management SLA on the Thanos 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 observability components that run continuously and are rarely cycled in production.

Is Echo's Thanos 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 Thanos deployments, the distroless variant is the leaner, more secure choice; for platform and SRE teams that rely on shell access for bucket inspection, configuration debugging, or Thanos CLI tooling, the default variant is the right fit.

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

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

Will Echo's Thanos 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 long-term metrics infrastructure under an ATO, Echo's hardened Thanos image keeps the observability layer in-boundary and compliant.