This repository was archived by the owner on Jun 21, 2022. It is now read-only.
Repository navigation
This repository was archived by the owner on Jun 21, 2022. It is now read-only.
Support SSL-enabled clusters without client cert auth. #13
Description
What version of Kubernetes (kubectl version) are you using?
1.7.3
What version of etcd (etcdctl --version) are you using?
3.2
What version of ReShifter are you using (for rcli: rcli version otherwise at the bottom of the app)?
v0.3.21-alpha
Reshifter currently assumes that any etcd endpoint with the https:// prefix is configured to require client authentication. Our current cluster configuration is setup such that the etcd endpoints are TLS-enabled, and signed by a common CA between the Kubernetes masters/workers/etcd nodes, but do not require a client certificate or credentials to be passed along with the request.
It would be swell to allow for requests to be https:// without requiring that the RS_ETCD_* variables be set.
I haven't written a ton of Go personally, but if you can point me in the right direction I'd also be interested in giving a go at a patch.
Reacted by Michael Hausenblas and Shane Starcher
Activity
mhausenblas commentedon Aug 23, 2017
@blardo thanks a lot for raising this issue, I think it makes a lot of sense. If you want to give it a try, it should be as 'easy' as patching:
reshifter/pkg/util/etcd3.go
Line 32 in 3f3ce15
That is, essentially providing a flag that creates a secure etcd3 client without the respective env variables.
One thing to remember is that the ReShifter library (i.e. everything under
pkg/is used by bothrcliand the app/HTTP API, so there will be different ways to pass the flag to the new function but I wouldn't worry about that for now. Or, put in other words: I'd focus on getting it done in the library and inrcliand I can then take care of getting it implemented in the app/HTTP API. Makes sense? :)blardo commentedon Aug 23, 2017
Makes sense to me - will have something ready to review in the next couple of days. Thanks!