New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Adding TLS to RPC #180
Comments
So I got it to compile and work with this // initialise service
service.Init(
micro.Action(func(c *cli.Context) {
if c.Bool("debug") {
log.Level = logrus.DebugLevel
log.Debug("Debug log level enabled")
}
}),
micro.Transport(transport.NewTransport(
transport.TLSConfig(tlsConfig),
)),
) But now the micro client strokes out with
|
Is the client actually using tls? |
I'm pretty sure no, I'm just using the micro cli tool I've tried
And
|
The micro cli does not currently support tls. The enable_tls flag is used to enable it for the http entrypoints; api, sidecar, web ui. You will need to setup tls yourself by switching out the default transport in go-micro/transport and compiling with that. The micro cli will make use of the default transport. Example tls.go file
rebuild with that
|
Might be awesome to figure it out with meta data - the service registers as using tls then the client should use tls. Less chance of cross channels. Thanks for that tho. |
Yea might be something to add but requires some work to do it without it being a hack. Also has the potential to be exploited in reverse where untrustworthy services are registered with no tls in a secure environment causing data to leak. There's no reason why a client could not be written to check metadata and do this but not sure it will be the default behaviour. |
Hmm yes, that's a concern, but perhaps that can be negated with a "requiretls" option - when you know you want tls, then require it. I know that sounds backwards, but I'm thinking from a dev perspective where they'll probably have a mix of tls and non tls while developing but they'll deploy to tls (although, I'm currently working on that being not the case with dev vault instances that |
Likely to spend more time thinking about it before actually implementing anything. A secure by default config would be nice but it's not quite simple. Please close the issue when satisfied that tls works. |
That doesn't seem to be working, looks like it's still trying to http transport. |
Try setting the transport in the client after setting it up.
|
package main
import (
"crypto/tls"
"github.com/micro/go-micro/client"
"github.com/micro/go-micro/transport"
)
func init() {
// initialise a tls config
t := &tls.Config{InsecureSkipVerify: false}
tr := transport.NewTransport(transport.TLSConfig(t))
client.DefaultClient.Init(client.Transport(tr))
} This works, now to convert everyone over to tls so I don't even have to deal with the tls vs not tls :D |
Decided to test it myself. When creating a service I set:
For the micro client I set:
This works. |
Cheers |
@asim : I tried what you mentioned, but the client and server still communicates even though they are set to true/false. I also tried with certificates:
` Client.go
` Here, even if the certificates are different on both sides, they still communicate. This is strange as I am facing this issue only in case of go-micro. |
Are you using go-micro with grpc? If so it ignores the transport and you need to set this in the client and server. |
Please don't comment on closed issues. Feel free to join the slack to discuss resolving this. Alternatively for direct support please ask Riverbed to pay for this. If you're using go-grpc please pay attention to the options https://godoc.org/github.com/micro/go-grpc#WithTLS |
{"id":"go.micro.client","code":500,"detail":"connection error: x509: certificate signed by unknown authority","status":"Internal Server Error"} Getting error in my client to hit sample.com:443, Kindly please help me in creating client |
I'm feeling a little bit dumb, I don't suppose you have an example of adding TLS to a RPC service?
I tried adding transport options to the service.Init but it's clearly not that simple?
The text was updated successfully, but these errors were encountered: