|
|
|
|
|
|
by sandeepkd
56 days ago
|
|
|
This is a good start, it does covers gaps in certain areas. There are few more areas I can think of 1. The end point matters, example if the credential is OAuth2 token and service has a token refresh endpoint then the response would have a new token in the payload reaching directly to the agent 2. Not all the end points are made the same even on the service side, some may not even require credential, the proxy may end up leaking the credential to such endpoints 3. The proxy is essentially doing a MITM at this point, it just increased its scope to do the certificate validation as well, to do it correctly is a hard problem 4. All credentials are stored on a machine, it requires a lot more access & authorization framework in terms of who can access the machine now. One might think that they closed a security gap and soon they realize that they opened up couple more in that attempt |
|
|
We're pretty swarmed on requests at the moment but I've noted these down as improvements to AV; it's a work in progress, we'll be molding it into the right shape over the next few months.
A few thoughts for each of the above:
1. AV doesn't consider OAuth2 tokens atm but this is definitely a next step.
2. Agree which is why there is a "passthrough" mode; for each endpoint, you need to explicitly specify what credential is used for it.
3. That's correct. This is a MITM architecture with credential brokering capabilities added on top.
4. Agree. The idea here is that AV can function both as a proxy and vault but in a true production setting, it should pull credentials from a secure secrets store like Infisical. This way credentials cached in memory in AV can even be made ephemeral.
Great observations all around and we have plans for them :)