[legobeet]

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/

[ghshephard]

Don't the "underprivileged canary tokens" then become privileged by virtue of being proxied into more privileged tokens?

[legobeet]

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)

[ghshephard]

Hashicorp Vault (and presumably other Enterprise credential management tools - like CyberArk's) has a, similar (but not identical - no proxy) take. The credentials that you use are short-lived and provided by vault, which has a privileged connection to the back end Database, AWS, Certificate Server, etc...

You can lock down access to vault with whatever degree of 2FA/IdP you wish. So - your workflow is authenticate to Vault, which uses your identity (and possibly group membership from an IdP like Okta) - to identify the groups/policies you have, which in turn then grant you the authority to request (short lived < 24 hours typically) tokens that are generated in real-time (and likewise terminated when they age out).

The added benefit here is that if your service token is exposed - (A) The window of vulnerability is very short lived, and, (B) it's isolated to a single service.

I haven't worked with Boundary - but it sounds like your solution has some closer comparison to Hashicorp Boundary, right?

[legobeet]

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

[rcxdude]

Yes, but this lets you sound an alarm if they're used from somewhere they shouldn't be (potentially quite tightly if you make the proxy also sound an alarm if the request comes from the wrong part of your internal network)