boundary
boundary copied to clipboard
[Bug] k8s address not injected when executing kube commands with '--' in args list
Describe the bug
When executing a kube command that requires -- in the arguments like kubectl exec; the connect command loses its cool
boundary connect kube -target-id target -- exec -it -n vault vault-1 -- sh
The connection to the server localhost:8080 was refused - did you specify the right host or port?
It takes the address from the kubeconfig
To Reproduce Steps to reproduce the behavior:
- Run
boundary authenticate ...
- Run
boundary connect kube -target-id <your_target> -- exec -it <pod> -- <command>
- See error
Expected behavior IT should just work :)
Additional context
Version information:
Git Revision: 15f8f63b2d11d750e03eb5d2318edf1565560d93
Version Number: 0.9.1
If I put a print statement in with your line above I see the --
being passed as a distinct argument:
[]string{"exec", "-it", "-n", "vault", "vault-1", "--", "sh", "--tls-server-name", "localhost", "--server", "https://127.0.0.1:54594/"}
So I don't know at the moment why this isn't working -- whether it's an issue with how Boundary is passing the args, with how kubectl
is parsing them, or something else (like shell behavior).
Marking as bug although when someone gets the chance to dig in it may not end up being a bug in Boundary 🤷
I have a similar issue:
$ boundary connect kube --target-id ${BOUNDARY_TARGET_ID} -- exec -it echo-server -- sh
sh: can't open '<kubernetes_api_url>': No such file or directory
command terminated with exit code 2
@jefferai could this be because of the double --
?
Maybe? It's hard to say. In theory the boundary connect
call should pass anything after the first --
straight through. In fact, we have an explicit avoidance of this situation:
for i, v := range args {
if v == "--" {
passthroughArgs = args[i+1:]
args = args[:i]
break // only consider the first instance of '--' in the args list
}
}
But maybe it's not working as expected.