https://github.com/legobeat/l7-devenv

E.g.

https://github.com/legobeat/l7-devenv/pull/144

https://github.com/legobeat/l7-devenv/pull/153

I daily-drove NixOS for a few years and philosophically very much vibe with the foundational ideas. Gave up on it because it was too much involved in getting productive with writing and maintaining nix configurations.

With this in mind:

- https://qubes-os.org - Use separate VMs for separate domains. Use disposable VMs for temporary sessions.

- https://github.com/legobeat/l7-devenv - My project. Separate containers for IDE and (ephemeral) code-under-test. Transparent access to just the directories needed and nothing else, without compromising on performance and productivity. Separation of authentication token while transparent to your scripts and dev-tools. Editor add-ons are pinned via submodules and baked into the image at build-time (and easy to update on a rebuild). Feedback very welcome!

- In general, immutable distros like Fedora Silverblue and MicroOS (whatever happened to SUSE ALP?) also worth considering, to limit persistence. Couples well with a setup like the one I linked above.

- Since you seem to be in a Node.js context, I should also mention @lavamoat/allow-scripts (also affiliated via $work) as something you can consider to reel in your devDeps: https://github.com/LavaMoat/LavaMoat/tree/main/packages/allo...

While you certainly can run Vault and Boundary independently, they are more designed to be deployed across an organization. Setting them up is anything but seamless - by design. Again, I think they can be complementary. Adding a Vault component to l7-devenv is a thought that came up before but I'll probably wait until popular demand before making anything public there. If you already have a setup it should not be too tricky to integrate, I think.

If you squint closer I think you can start seeing even more parallels to HC solutions but that is more because none of these patterns are really fundamentally new but the building blocks of we've all been doing for decades. It's just new clothes and ways to make things play together nicely (xkcd 927). And hopefully we can bring these strategies like mTLS to new audiences and bring down barriers for adoption of secure practices in general.

> no proxy

Look again ;) (Envoy)

As opposed to something which can be smuggled out and reused offsite.

I'm also thinking that by centralizing (still locally) the configuration, we can get better key rotation hygiene habits without needing to compromise on credential granularity .

Just like there are security benefits in using a secured HSM instead of a world-readable private-key file stored in your unencrypted home directory, even if, yes, the HSM can be abused by a locally privileged attacker.

(I'm definitely not saying I have a silver bullet though, and I don't think one exists. Like any realistic solution, it should be part of a defense-in-depth strategy. Things like hardware keys make for incremental gains, etc)

For example, an application-specific HTTP proxy for your GITHUB_TOKEN. You can use a canary token for the internal user-facing auth. https://github.com/legobeat/git-auth-proxy [0].

That piece is being used here[1] in order to make it transparent for the user and I intend to add more features there for credentials- and secrets compartmentalization. Been keeping it fairly structured so you could also use it as a reference if you ever do similar stuff and want some inspiration or copypasta for your personal hacking.

[0]: Caveat: The proxy repo is a fork and the documentation is still more reflective of the previous owners intentions. I ripped out all the Azure/k8s integrations.

[1]: https://github.com/legobeat/l7-devenv/

https://github.com/pvolok/mprocs

https://github.com/legobeat/l7-devenv

Something like Lokal might till be useful here to facilitate remote collaboration by providing a tunnel (ie I can connect to your local session behind NAT without you opening ports or connect to VPNs etc).

I don't think it has to be this way. I think we can have both better compartmentalization and tighter workflow integration without having it becoming a part-time job.

Here is my ongoing attempt at addressing the issue, currently scoped for neovim[0]:

https://github.com/legobeat/l7-devenv

(I did share this to crickets as a Show HN the other day, hope it's on-topic enough to OK to reshare here)

[0]: The same framework should, at least in theory, be extensible to do something similar with Code/VSCodium. While working on this I realized there is some overlap with their Dev Containers and am yet to look into if and how one would run those in a similar fashion and if they could be leveraged to the same end

l7-devenv, or `de` for short[0], is a containerized terminal-based IDE using rootless Podman, neovim and friends, and proxying of network requests and sockets.

IMO, the security story around most widely used code editors is not great today. Security, convenience, and productivity appear to be pick-any-2 when fundamentally I believe they don't have to be in conflict.

`de` takes a critical look at the software and secrets used for day-to-day development and compartmentalizes them using containers. For example, you can connect seamlessly to authenticated GitHub endpoints without leaking your production token while LSPs and package scripts are run in separate ephemeral containers. It also provides features and integrations to make the developer experience more productive and joyful, with a current focus on Node.js development[1], GitHub, and web3.

The main and integrated editor is neovim. No plugin manager is used; instead plugins are installed natively from git submodules and bundled into the image.

This is currently in a prototype stage[2] and driven by internal needs. It derives heavily from existing community efforts (<3).

You will find this relevant if you want:

- To be using neovim for Node.js development and collaborating on github.com

- Separate your developer credentials from your editor and code-under-test

- More control of your https requests[3]

- Something more secure than distrobox but more lightweight and seamless than QubesOS (<3)

- More terminal joy and less waiting at requests to load for your routine code review workflows

- Some inspiration for your own setup

---

[0]: Names WIP

[1]: While current focus is catering to JS/TS devs, it should be straightforward to add your own runtimes and buildtimes. There is an example for golang in there if you look around.

[2]: Provided as-is, currently no guarantees given regarding actual security, etc. In particular, the proxied container socket used to spawn side-containers could definitely use some tightening down.

[3]: The TLS MitM is already done and redirecting the current proxy to something like mitmproxy should be trivial for the motivated

Comments URL: https://news.ycombinator.com/item?id=40871782

Points: 4

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=40763117

Points: 230

# Comments: 111