legobeet

I'm going the container route. To get the full seamlessness you're alluding to (easily switch between multiple parallel environments; easy migrations) still requires some additional features but perhaps you can find some inspiration.

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

E.g.

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

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

In a similar vein but still containers and a bit more targeted: http://github.com/legobeat/l7-devenv

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.

A defense-in-depth approach with a special eye to compartmentalization/separation/sandboxing coupled with principle-of-least privilege is a good stance to take, I think. Also keep in mind that "security is a process, not a product". There is no silver bullet no tool will save you from yourself...

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...

What I am proposing is something you'd run on your independent workstation to interface with existing heterogeneous services and peers.

While you certainly can run Vault and Boundary independently, they are more designed to be deployed cross an organization. Again, I think they are complementary.

If you squint closer I think you can start seeing even more parallels to HC solutions but that is more because none of this is really fundamentally new and is what 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.

Sure, but they are only usable as such if attackers also maintain access to the proxy and stay under the radar. Additionally, the proxy has logging and hooks for monitoring so you can audit and filter usage there.

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)

The next step is to actually use underprivileged canary tokens on the client for your day-to-day work, intercept them with a proxy, and replace them with the real deal in a more isolated setting.

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/

mprocs is worth checking out!

https://github.com/pvolok/mprocs

Here's a batteries-included local-first dev-environment which does that in order to compartmentalize your credentials:

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).

The security side of free editors and IDEs is not great anywhere today for JS development. Once you start wanting more features and integrations, you start facing an apparent choose-any-2 of security, convenience, and productivity.

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