3 ms·
what's to stop an agent creating an outbound call with the var to a malicious endpoint? (unless you whitelist what it has access to)
by kellpossible2 2mo ago
what'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
- messh 2mo agoBut then... why is replacent needed at all: just use sone permissions system.
- messh 2mo agoCouldn't the agent post then the key in some public comment?
- roywiggins 2mo agoOnly if the replacement is global and not, say, only looking and inserting it into the actual (eg) Authorization header. If something is only transparently altering the Authorization header, then an agent inserting the dummy value somewhere else is totally safe.
- mikesir87 2mo agoFor clarity, there is no "search and replace" function going on. It's only setting the header. The main reason a "proxy-managed" env var is set is because most CLI tools assume if the env var is set, auth is set. If the env var is unset, it will assume auth needs to occur. Fortunately, most don't do a pattern matching on what the value actually is.
- skinfaxi 2mo agoThe replacement is on a url/host basis.