Comments

Hacker News

What happens if the "fake" key gets compromised?

by trallnag

This is the same old good way from database world. A db client never touches the disk, but sends requests to a server who owns it. Same in your product. Keys are separated from agents and if needed, agents must send request to a proxy who owns them. Old proven design. Good luck.

by osinix

Oo this is interesting, blocking it on the network level is nice

by redbridgerock

does the agent control the environment that onecli is running in? (yes)

by doctorpangloss

MITM is a feature now.

by vayup

How does it compare to agent-vault and clawpatrol?

by emilsoman

It works great for static credentials. As a product I think about adding couple more things that might be helpful here (Btw I am not the client for this, I just happen to know them as practical problems)

1. Support for OAuth Client credentials - Gateway does the OAuth dance to get the access token, this is quite practical and even useful in case of regular services running across clusters and sharing the same clientId-secretId

2. Support for request retries on certain failures and short circuiting in other cases

by sandeepkd

Join the discussion

Write your take first — we'll ask for email only when you're ready to publish.

  • Hacker News
  • What happens if the "fake" key gets compromised?
  • This is the same old good way from database world. A db client never touches the disk, but sends requests to a server who owns it. Same in your product. Keys are separated from agents and if needed, agents must send request to a proxy who owns them. Old proven design. Good luck.
  • Oo this is interesting, blocking it on the network level is nice
  • does the agent control the environment that onecli is running in? (yes)
  • MITM is a feature now.
  • How does it compare to agent-vault and clawpatrol?
  • It works great for static credentials. As a product I think about adding couple more things that might be helpful here (Btw I am not the client for this, I just happen to know them as practical problems)

    1. Support for OAuth Client credentials - Gateway does the OAuth dance to get the access token, this is quite practical and even useful in case of regular services running across clusters and sharing the same clientId-secretId

    2. Support for request retries on certain failures and short circuiting in other cases