5 ms·
Does secret injection really prevent that the agent send my GitHub key somewhere? If it has access to it via env var, can it not just paste it somewhere?
by _ink_ 2mo ago
Does secret injection really prevent that the agent send my GitHub key somewhere? If it has access to it via env var, can it not just paste it somewhere?
- rusch 2mo agoThe env var is just a placeholder in the VM, so no real secret is in there.
- llimllib 2mo agoright, but say you give the agent access to github and it can push as you, or make a gist; now it can easily exfiltrate your secret. And that's just an easy case - really if it has any network access at all it can come up with a clever way to route a request through the network such that the key comes back somewhere in the request. If you scan for it inbound too, the machine can obfuscate it. Our agents are trained to be so intensely helpful and they have such intricate knowledge of how things work that they will do some incredibly clever tricks to do what you ask them to do.
- skinfaxi 2mo agoThe agent has no access to the secret. It has a placeholder that is replaced at a higher level. When it makes the network request the secret is substituted but that is outside of the caller's worldview.
- Eldt 2mo agoSo what stops it from sending a network request to a git repo that pushes what that placeholder resolves to?
- skinfaxi 2mo agoHow would that work? You don't control github.com servers so your repo would never see the secret. edit: You may want to look into tokenizing proxies as the general application of this concept.
- llimllib 2mo agoYour agent writes secret.txt with the placeholder, and the tokenizing proxy replaces it with the token, then the agent reads secret.txt
- skinfaxi 2mo agoIt only replaces the token in the HTTP header that is sent to the server. Whatever you wrote in your files isn't touched by the proxy.
- drdexebtjl 2mo agoMaybe the tokenizing proxy could work both ways? If the agent tries to read secret.txt, it gets back the placeholder.
- messh 2mo agoCouldn't it then just publish the mock in a public place... it would get replaced by the real secret.? How is this prevented
- ruszki 2mo agoBut how? Normally the TLS handshake and encryption/decryption happen in user space. Even the kernel doesn’t know anything about it.
- icedchai 2mo agoThere is a transparent proxy installed (along with the necessary certificates on the VM.) For an example, see https://docs.microsandbox.dev/networking/tls https://docs.microsandbox.dev/networking/tls
- ruszki 2mo agoSo, if the program or the proxy solution doesn’t support it, then it doesn’t work? Like with security solutions?
- icedchai 2mo agoThe docs mention it can be bypassed for configured domains.
- ruszki 2mo agoYes, I read it. That means that it doesn’t work in those cases. Btw, as a developer it’s very easy to have something like that. It’s not as trivial as it seems at all. I encountered with similar problems all the time, with similar solutions (mainly for security theater reasons) in the past. There are websites which simply doesn’t work if you replace certificates, regardless of browser or CA for example.
- icedchai 2mo agoYes, I've worked with people who have run into issues with "security" solutions like ZScaler. I have tried it with some APIs (like GitHub) and it does work. Not to say it will work in your case.
- eli 2mo agoIt’s injected into an outbound api call, not into an env var the agent can read.
- kellpossible2 2mo agowhat's to stop an agent creating an outbound call with the var to a malicious endpoint? (unless you whitelist what it has access to)
- eglintondust 2mo agoYou just don't inject the real secret unless hostname/whatever rule matches the request, right? I don't know if that's how this works but it's my assumption.
- mikesir87 2mo agoOn the Docker DevRel team... yes! This is it. The secret is injected only into headers in which the hostname matches. There's also an ability to create kits where you can setup credential injection into other services as well.
- mpern 2mo agoAt least for gondolin and microsandbox, you bind a specific secret placeholder to the target host. i.e. your GH token is only replaced/injected for calls to api.github.com, not other hosts. And you can set up both with deny-by-default
- deleted 2mo ago[deleted]