On Tue, Nov 12, 2019 at 9:52 AM Sage Weil <sweil@xxxxxxxxxx> wrote: > > Right now the way ceph-daemon is used by the ssh orchestrator is designed > to minimize the dependencies/setup complexity. The only requirements for > a host to be added to the cluster are > > - python (2 or 3) > - systemd > - either podman or docker installed > - the ceph cluster's pub key in /root/.ssh/authorized_keys > > No other software (including Ceph) needs to be installed. The mgr/ssh > module invokes ceph-daemon on the remote host by running /usr/bin/python > over ssh and piping the cluster's version of ceph-daemon to stdin. > > The downside to this approach is that some users might not like the idea > of ceph having an ssh key with root access. For large clusters I'm not > sure how much this really matters--if you pwn ceph you can delete TB to PB > of data so do you really care if someone has root?--but for hyperconverged > cases this might be a problem. > > One alternative might be to > > - create a ceph user on the node, and put the cluster's key in > that user's authorized_keys > - install a package that includes ceph-daemon (/usr/bin/ceph-damaen) > - install an /etc/sudoers.d/ceph file that lets the ceph user > 'sudo ceph-daemon ...' > > Cons: > - This makes the bootstrap process slightly more complicated: (1) install > package, (2) create user, (3) install ssh key (vs just #3). > - The remote version of ceph-daemon can get out of sync with the > cluster.. either stale and missing some feature, or even too new and > not behaving the way the cluster expects. > > Pros: > - This limits the attack surface area (if someone manages to get the > cluster's ssh key) to the functions that ceph-daemon implements, vs > full root. > > We could mitigate the 'keep ceph-daemon up to date' problem somewhat by > implementing a 'ceph-daemon update' function that will apt/dnf/yum install > ceph-daemon on the local host, so that the cluster could self-update the > remote host. > > Or... we could skip the package entirely and install the ceph-daemon > script in /home/ceph/ceph-daemon, and include an update function that > updates the script in place. That is less complicated than knowing how to > apt/dnf/yum install a package for all the random distros and repo location > combinations (one of the biggest benefits of containers IMO). But it > still requires some sort of process to keep ceph-daemon up to date. > Maybe if we always pass an md5sum to ceph-daemon whenever we invoke it to > assert that we are running the version we want, and if there is a > mismatch, ceph-daemon bails out with a special exit code that triggers and > update and retry? Updating a system executable via its own - circumventing distro's packaging policies isn't something that is going to be easy to sell. > > Anyway, what are people's thoughts here? How much more complicated are we > interested or willing to make this to make people more comfortable with > the idea that ceph owns an ssh key? Why would this need to be solved by ceph-daemon at all? In other software (Vagrant for example) that has similar needs, an "insecure" SSH key is provided so that initial setup (or bootstrap) is done with ease. It is up to the administrator to ensure that key is updated after bootstrapping or create a separate SSH user with restrictions. In lots of cases this step of securing the SSH key is not needed, like testing or playing around with a throwaway cluster. > > sage > _______________________________________________ > Dev mailing list -- dev@xxxxxxx > To unsubscribe send an email to dev-leave@xxxxxxx > _______________________________________________ Dev mailing list -- dev@xxxxxxx To unsubscribe send an email to dev-leave@xxxxxxx
