For fine-grained authorization, Open Policy Agent (a CNCF incubating project) easily integrates with PAM (https://www.openpolicyagent.org/docs/latest/ssh-and-sudo-authorization/). There's a dockerized demo ready to use at: https://github.com/open-policy-agent/contrib/tree/master/pam_authz. That one uses keyboard-interactive log-on, but it can be easily switched to publickey. For the authentication, if you don't want to mess with authorized_keys and root, you can make sshd trust a CA instead (https://smallstep.com/blog/use-ssh-certificates/). BTW, by using a CA you can also avoid ssh's TOFU issue (host keys can be signed by the CA too). Kind regards, Ernesto On Tue, Nov 12, 2019 at 3:52 PM 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? > > 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? > > 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
