Fix k8s execute command argv handling#67
Conversation
d74d0ad to
f3e42ee
Compare
Signed-off-by: DParikh_flexera <Dparikh@flexera.com>
f3e42ee to
f27c8ac
Compare
|
Hi @EItanya @dimetron, I noticed CODEOWNERS routes this repo to you, so I wanted to gently flag this PR for review. I hit this while validating kagent exec through Teams/A2A: the request reached kagent-tools correctly, but |
|
Hi maintainers, just following up here in case this got buried. I would be grateful for a review when someone has a chance. The change is intentionally small: it preserves the existing command-string path, adds structured argv handling for exec-style calls, and wires through container selection. I am happy to adjust the shape if you would prefer a different API. Thanks for maintaining this! |
Why
While testing Kubernetes exec through kagent from a Teams bot, I ran into a confusing failure mode: asking the agent to run
uname -ainside a pod reachedkagent-tools, but Kubernetes tried to execute a binary literally nameduname -a.That made the whole A2A/MCP path look broken at first, even though routing, auth, approvals, and the target pod were all working. A single-word
unamesucceeded, which narrowed the issue down to howk8s_execute_commandbuilds thekubectl execargv.This PR fixes that sharp edge so simple exec commands behave the way users and agents naturally expect.
What changed
argsarray for flags/arguments, so callers can send structured input such ascommand: "uname", args: ["-a"].command: "uname -a".containerinput by passing-c <container>tokubectl exec.Fixes #59.
Testing
go test ./pkg/k8sk8s_execute_commandsucceeds withcommand: "uname", args: ["-a"], container: "twistlock-defender".command: "uname -a".kagent-toolslogs showed kubectl invoked as separate argv pieces:exec ... -c twistlock-defender -- uname -a.