Alan: i don't know all the details, but
SOLR-6915 is pretty much on point here in terms of letting solr read/write what it needs to in ZK, while some subset of users can modify configs, while other clients/users may only have read access to ZK.
just because someone can create CloudSolrClient instance and get the list of active nodes from ZK doesn't mean they can/should be allowed full write access to ZK.
EDIT: to clarify my point: i'm not saying we shouldn't support this in CloudSolrClient, i'm saying if we support it, we need to keep the security conious use case in mind and ensure we have a good story/docs for folks who care about things like
SOLR-6915 ... maybe it "just works" because the ZK credentials used when constructing the CloudSolrClient instance are prevented from writing to those config nodes in these secure cases, and they returne a good error message ... but we should think about that and test it.