Hacker News new | ask | show | jobs
by sakisv 58 days ago
This feels like a good idea in principle, but I can't shake the feeling that it just moves the goalposts one step away:

Now your app doesn't have direct access to your stripe/github/aws/whatever keys (which is good!) but you still need to have _some_ authentication against your proxy.

If you have a per-app authentication, then if your app's key leaks, then whoever uses it will be able to reach all the external services your app can, i.e. with one key you lose everything. On the other hand, if you have per-endpoint authentication, then you didn't really solve anything, you still have to manage X secrets.

Even worse, from the perspective of the team who owns and runs the proxy, chances are you are going to use per-app AND per-endpoint authentication, because this will allow you to revoke bad keys without breaking everyone else, etc.

What this really solves is subscription management for (big?) organisations. Now that you have a proxy, you only need a single key to talk to <external-service>, no need to have to manage subscriptions, user onboarding and offboarding, etc. You just need to negotiate ratelimits.

1 comments

The auth between your app and the proxy can be scoped more easily.

For example if the proxy runs in localhost you can trust the localhost workload.

Or you can use some other kind of workload identity proof (like cloud based metadata servers). If you leak such a key no other VM can use it, because it's scoped to your VM

That's not true. Both AWS' as well as GCP's workload identity tokens are not bound to the VM. If you leak the credentials they're valid until they expire. on AWS the expiry is 6 hours (non-configurable). Even if your IAM role has a shorter expiration, the credentials assumed by the VM will always be valid for 6 hours.
That entirely depends on the location of the proxy and the extra conditions you can express. E.g. you could bind it to a source IP and have the proxy check that, or use some overlay network (like tailscale does)

My point was that you don't literally have to run the proxy on localhost in order to scope the request.