The current way option arguments are parsed and passed to curl is broken. Options are currently passed to curl like --arg=value when curl wants them as --arg value. This was addressed in issue https://github.com/segmentio/kubectl-curl/issues/6 and this PR fixes that and more.

The crux of this PR was to get this example working:

kubectl curl --debug -iv -H "Content-Type: application/json" -H "X-Auth-User: bob" http://pod-555464c988-2jb6r:3000/internal/health

The fix to get the curl options in the correct form was to pass the argument name and value separately to cmd := exec.CommandContext(ctx, "curl", cArgs...). But if you then specify two arguments with the same name and different values like in the example above with multiple headers, only the last header option is passed to curl.

I couldn't see a straightforward way to do this with the current spf13/pflag implementation, and since the -d/--data option and likely many others support specifying multiple options with curl, I got a little creative. This implementation still validates that the options passed are valid options, but when multiple are present for curl, it just passes those onto curl to let curl handle the validation, like if multiple options are present when they shouldn't be.

I don't see any unit tests or a simple way to make some. I tested variations of my use cases above, but not anything on the k8s options side eventhough they should be unaffected, so give it a try.

ubuntu 20.04 go version go1.13.8 linux/amd64

go get github.com/segmentio/kubectl-curl@latest build github.com/segmentio/kubectl-curl: cannot load io/fs: malformed module path "io/fs": missing dot in first path element

While trying to use -X POST, the plugin complains such argument is invalid (set URL and CONTAINER to some valid values). I have seen a similar behavior while using -d.

$ kubectl curl -i -X POST $URL $CONTAINER
curl: option --request=POST: is unknown
curl: try 'curl --help' or 'curl --manual' for more information

Reproduced in both macOS and Ubuntu 20.04. Details below.

MacOS environment:

$ curl --version
curl 7.77.0 (x86_64-apple-darwin21.0) libcurl/7.77.0 (SecureTransport) LibreSSL/2.8.3 zlib/1.2.11 nghttp2/1.42.0
Release-Date: 2021-05-26
Protocols: dict file ftp ftps gopher gophers http https imap imaps ldap ldaps mqtt pop3 pop3s rtsp smb smbs smtp smtps telnet tftp
Features: alt-svc AsynchDNS GSS-API HSTS HTTP2 HTTPS-proxy IPv6 Kerberos Largefile libz MultiSSL NTLM NTLM_WB SPNEGO SSL UnixSockets

$ kubectl version --client
Client Version: version.Info{Major:"1", Minor:"19", GitVersion:"v1.19.2", GitCommit:"f5743093fd1c663cb0cbc89748f730662345d44d", GitTreeState:"clean", BuildDate:"2020-09-16T21:51:49Z", GoVersion:"go1.15.2", Compiler:"gc", Platform:"darwin/amd64"}

$ sw_vers
ProductName:	macOS
ProductVersion:	12.0.1
BuildVersion:	21A559

Linux environment:

$ curl --version
curl 7.68.0 (x86_64-pc-linux-gnu) libcurl/7.68.0 OpenSSL/1.1.1f zlib/1.2.11 brotli/1.0.7 libidn2/2.2.0 libpsl/0.21.0 (+libidn2/2.2.0) libssh/0.9.3/openssl/zlib nghttp2/1.40.0 librtmp/2.3
Release-Date: 2020-01-08
Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps pop3 pop3s rtmp rtsp scp sftp smb smbs smtp smtps telnet tftp
Features: AsynchDNS brotli GSS-API HTTP2 HTTPS-proxy IDN IPv6 Kerberos Largefile libz NTLM NTLM_WB PSL SPNEGO SSL TLS-SRP UnixSockets

$ kubectl version --client
Client Version: version.Info{Major:"1", Minor:"23", GitVersion:"v1.23.1", GitCommit:"86ec240af8cbd1b60bcc4c03c20da9b98005b92e", GitTreeState:"clean", BuildDate:"2021-12-16T11:41:01Z", GoVersion:"go1.17.5", Compiler:"gc", Platform:"linux/amd64"}

$ lsb_release -a
LSB Version:	core-11.1.0ubuntu2-noarch:security-11.1.0ubuntu2-noarch
Distributor ID:	Ubuntu
Description:	Ubuntu 20.04.3 LTS
Release:	20.04
Codename:	focal

This PR fixes the use of boolean options, which were forced to have a value before.

The issue came from the pflag package not detecting boolean values via implementation of interface{ IsBoolFlag() bool } like the standard flag package does, and instead of relying on setting the NoOptDefVal being assigned.

I also improved a few usage error messages.

I installed kubectl-curl from the README and ran into an error.

Install:

$ go install github.com/segmentio/kubectl-curl@latest 
go: downloading github.com/segmentio/kubectl-curl v0.1.5

Error:

$ kubectl curl http://{pod}/metrics
* ERROR: malformed URL: parse "http://{pod}/metrics": invalid character "{" in host name

Hi! We use go-teleport installed at say tele.host.com. Using kubectl curl I get this:

m ~/D/  kubectl curl -vvv --debug "http://{podname}:3000/healthz"
* 2022/05/15 21:46:39 kubectl get -n default pod/{podname}
* 2022/05/15 21:46:41 forwarding local port 14187 to port 3000 of
* 2022/05/15 21:46:41 waiting for port fowarding to be established
* 2022/05/15 21:46:41 error upgrading connection: error sending request: Post "https://ele.host.com:3026/api/v1/namespaces/default/pods/zenith-console-7c64d658bd-mqvdv/portforward": dial tcp: lookup ele.host.com: no such host
^C* 2022/05/15 21:47:00 shutting down port forwarder
* 2022/05/15 21:47:00 waiting for port forwarder to stop

and it hangs forever. There is obviously no ele.host.com. Cause it's tele.host.com. Can't say for sure, this is not a go-teleport bug, sorry.

Would it be possible to distribute this plugin via Krew? I believe this would help with the discovery of this plugin & simplifying the installation process 🙂