Comment 2 for bug 1894870

comments from Greg W over email:
I can NOT recall whether it was a conscious decision to not secure or authenticate etcd in StarlingX ... or an oversight.
( ... I added a few more starlingx types to see if they remember anything ... )

My only guess is that “maybe”, initially when we were focusing primarily on the openstack containerized application, the fact that etcd was restricted to the cluster-host network which was affectively the same as mgmt network which was a PRIVATE network, and applications were in VM network space ... there was no need to secure/authenticate the privately deployed etcd.

... but this is not the case anymore.

At a high-level, I am ok with your suggestion to use TLS client authentication to secure and authenticate etcd clients.

Wrt possible impacts on other system use cases:
• Backup & Restore
o I suspect you’d have to ensure that the client certificates along with trusted client certificates would have to be backed up and restored after this feature is turned on .
• Software upgrade
o Rolling upgrades (node by node) are possible today with software upgrades ... we wouldn’t want to break that.
o i.e. during a rolling upgrade would an v.N(noauth) client be talking to a v.N+1(auth) etcd ?
• Controller switchovers, etc
o Client certificates would have to be synchronized across any nodes (controllers or workers) that use etcd clients to talk to etcd
• ??? any other considerations ???