Open dmitris opened 5 years ago
CC @bradfitz @FiloSottile @jayconrod
I think the array of possible authentication schemes is too wide, so these should be handled by a local GOPROXY that exposes the unauthenticated protocol to the client, and does whatever authentication you want to the upstream.
I'm starting to think it would be nice to let GOPROXY be a binary that the go tool runs itself, so that a GOPROXY can be made even for small tasks, without having to run a network service on the local machine, which is a lot of friction.
I think a drawback of the local GOPROXY solution is that everyone running go who has to play the authentication game would need not just set some environment variables but would have to obtain / install / keep up-to-date, and make sure go
can find and execute that separate program - in addition to setting an environment variable for GOPROXY. It also seems to open an additional security attack vector - at the least, you have to worry what kind of "interesting" compromises would become possible through the local GOPROXY binary. Personally for mTLS I would prefer to be able to tell go
where to pick up cert/key/cacert from then deal with creating (?) / setting up additional binary.
Let's get the basic HTTP auth stuff working first (#26232) and then circle back to thinking about even more exotic authentication like TLS client certs.
It would be very useful for us to be able to pass a client certificate to the go
tool. I guess this issue is different from #26232, because no text/html is transmitted without an tls handshake. So it cannot be fixed by extending to access-denied page.
I agree with @dmitris to keep the number of local tools small and would argument that if an -insecure
flag exists, a -client-cert
(or a matching environment variable) would be valid.
I'm looking forward to see updates on this and let me know if I can help in some way.
There is a temporary solution. I use a MITM tool to provide client certificates. Like this:
mitmdump --listen-host ${ip_address} --listen-port ${port} --ignore-hosts=${whitelist} --set client_certs=${cert}
And set
go env -w GOPRIVATE="your company repo"
I'd really love to be able to use client certificates as well.
Any chance we get this implemented? I'd try to provide a pull request if there's any interest.
It would be useful to be able to pass to the
go
tool a client TLS certificate + key + CAcert (in environment variables or otherwise) - especially, in environments that take Zero Trust Network (ZTN) seriously and wherego
tool needs to talk to the other side (thereplace
targets) that lives in a public cloud using mutual TLS for authN/Z. The "other side" can be either a GOPROXY server or a redirector (likegolang.org
) serving the meta tags. Since one of the ZTN principles is "every network connection must be authenticated and authorized", the question is how to implement it with the go tool and the requests it initiates.Technically, it possibly comes down to how to pass desired TLS options (key/certificate/cacert filenames or such) to
tls.Config
thatgo
would use when initiating connections.