mirrord VS cargo-auditable

So, you've been using mirrord to simplify your development process (if you haven’t, go here!). Naturally, you want the traffic from the app you're debugging to go through the cluster environment, so your app can communicate with its clustery pals. There is a problem though: your latest change adds some new columns to the database, and you don’t want to modify the database in the cluster and affect everyone else working on it. You do have a local instance of the database that you can modify, so your app can use that, but you still want it to talk to all the other components in the cluster. So what now? The new outgoing traffic filter feature is here to solve exactly this type of problem!

I had the pleasure of talking to Eyal @ CTO at Metalbear and the maintainer of Mirrord. I got some crazy insights.

If you want to take mirrord for a spin, check out the quick start guide. We’d love to hear about your experience or just general thoughts - chat us up on our Discord or open an issue or discussion on GitHub.

We're building an open-source tool called mirrord which lets you run a local process in the context of a pod in your cloud environment. We often get asked how mirrord is different from Telepresence and so we decided to write a short blog post about it, which we hope would be valuable to those interested in local Kubernetes development:

Hands-on tutorial of mirrord.dev with the creators and Rawkode!

if you are interested in k8s, iptables, hooking libc, asm etc https://github.com/metalbear-co/mirrord

I gave my first CNCF talk in Toronto yesterday, talking about https://github.com/metalbear-co/mirrord , how all the features work, and how it's engineered!

Further we use cargo-auditable and cargo-audit as part of both our pipeline and regular scanning of all deployed services. This makes our InfoSec and Legal super happy since it means they can also monitor compliance with licenses and patch/update timings.

This exists, see cargo auditable.

The Rust community seems to have settled on a perfectly reasonable way to address bit-rot in statically linked binaries. https://github.com/rust-secure-code/cargo-auditable

Would you be open to integrating cargo auditable into this pipeline in some form? It seems like a great match.

> and static compilation probably just hides the problem unless security scanners these days can identify statically compiled vulnerable versions of libraries

Some scanners like trivy [1] can scan statically compiled binaries, provided they include dependency version information (I think go does this on its own, for rust there's [2], not sure about other languages).

It also looks into your containers.

The problem is what to do when it finds a vulnerability. In a fat app with dynamic linking you could exchange the offending library, check that this doesn't break anything for your use case, and be on your way. But with static linking you need to compile a new version, or get whoever can build it to compile a new version. Which seems to be a major drawback of discouraging fat apps.

1: https://github.com/aquasecurity/trivy

2: https://github.com/rust-secure-code/cargo-auditable

I have investigated a bunch of standardized formats - SPDX, CycloneDX, etc. All of them are unsuitable for a variety of reasons, chief of which are being way too verbose and including timestamps, which would break reproducible builds.

The fix for interoperability with cargo auditable has also shipped in the latest release of sccache. You can use the released sccache now instead of building it from git!

I've been working to bring vulnerability scanning to Rust binaries by creating cargo auditable, which embeds the list of dependencies and their versions into the compiled binary. This lets you audit the binary you actually run, instead of the Cargo.lock file in some repo somewhere.

cargo auditable solves this problem by embedding the list of dependencies and their versions into the binaries. But until it becomes part of Cargo and gets enabled by default, static linking will remain problematic.