Closed kuon closed 9 years ago
We have considered supporting this use case and have changed all of the new flags in etcd 0.5.0 to take full URLs so some listeners can be http and other https. But, there is a additional plumbing required to do it. In the meantime I am going to set this for the 0.6.0 milestone.
If you want to contribute a patch to locksmith or etcd to fix this up it would be greatly appreciated too.
Thanks.
I also tried using SSL for both peer and client connections, this works, but the problem is that all clients needs to connect via SSL, for example "locksmith" doesn't support SSL.
Actually FWIW TLS support has been added to locksmith as of version 0.2.0, which should make it into the next alpha release of CoreOS
I am still evaluating CoreOS. I'll try with the next alpha, and if I see something is missing, I'll submit a patch.
My nodes are on a public network, which requires me to use SSL and authentication for communication between them.
I tried to use SSL only for the peer communication on port 7001, but it doesn't work when a client request a consistent value on a node that is not the master.
This works:
but this return a redirect to
127.0.0.1
yielding to a redirect loop:This mixed setup (where etcd listen on 127.0.0.1 on port 4001 and peers communicate via SSL on port 7001) would be ideal as clients can just connect without authentication from the localhost.
I also tried using SSL for both peer and client connections, this works, but the problem is that all clients needs to connect via SSL, for example "locksmith" doesn't support SSL.
My options are:
What is the best practice for this? Having a cluster of machines with public IPs seems to be quite a common practice. (the latency between machines is never more than a few milliseconds)