ceph秘钥管理机制

引言

这篇文章主要介绍了 Ceph 中的一个重要系统 – CephX 认证系统。简要介绍了 CephX 的命名格式。并介绍了从集群启动到用户连接集群这一系列流程中 CephX 所起的作用。最后通过实验操作讲解如何在集群所有秘钥丢失的情况下将其完整恢复，以及在实际生产环境中使用 CephX 的一些注意事项。

CephX 是什么？

CephX 理解起来很简单，就是整个 Ceph 系统的用户名/密码，而这个用户不单单指我们平时在终端敲 ceph -s 而生成的 client，在这套认证系统中，还有一个特殊的用户群体，那就是MON/OSD/MDS，也就是说，Monitor， OSD， MDS 也都需要一对账号密码来登陆 Ceph 系统。

CephX 的命名规则

而用户名/密码遵循着一定的命名规则：
用户名：
用户名总体遵循 <TYPE . ID> 的命名规则，这里的TYPE有三种： mon,osd,client。而 ID 根据不同的类型的用户而有所不同：
mon ： ID 为空。
osd ： ID 为 OSD 的 ID。
client ： ID 为该客户端的名称，比如admin,cinder,nova。
密码：
密码通常为包含40个字符的字符串，形如：AQBh1XlZAAAAABAAcVaBh1p8w4Q3oaGoPW0R8w==

默认用户

想要和一个 Ceph 集群进行交互，我们通常需要知道最少四条信息，并且是缺一不可的:
1、集群的 fsid。
2、集群的 Monitor 的 IP 地址，必须先连上 MON 之后才能获取集群信息。
3、一个用于登陆的 用户名。
4、登陆用户对应的 密码。
其实，很多同学会发现，在我们日常和 Ceph 集群交互时，并不需要指定这些参数，就可以执行 ceph -s 得到集群的状态。实际上，我们已经使用了 Ceph 提供的几个默认参数，而 ceph -s 加上默认参数后的全称是：
ceph -s --conf /etc/ceph/ceph.conf --name client.admin --keyring /etc/ceph/ceph.client.admin.keyring
从上面的指令可以看出，Ceph 使用的默认用户为 client.admin，而这个用户的秘钥文件通常是保存在/etc/ceph/ceph.client.admin.keyring 路径下。如果这里，我们从/etc/ceph目录下删除这个秘钥文件，再次执行 ceph -s，就会得到下面这个最最常见的错误：

2017-07-28 15:56:03.271139 7f142579c700 -1 auth: unable to find a keyring on /etc/ceph/ceph.client.admin.keyring,/etc/ceph/ceph.keyring,/etc/ceph/keyring,/etc/ceph/keyring.bin: (2) No such file or directory
2017-07-28 15:56:03.271145 7f142579c700 -1 monclient(hunting): ERROR: missing keyring, cannot use cephx for authentication
2017-07-28 15:56:03.271146 7f142579c700 0 librados: client.admin initialization error (2) No such file or directory
Error connecting to cluster: ObjectNotFound

从报错信息我们可以看出一点，因为我们使用了默认用户 client.admin，Ceph 就会以下四个默认路径去寻找 client.admin 这个用户的密码：

/etc/ceph/ceph.client.admin.keyring ： 实际上命名格式为： /etc/ceph/<$cluster>.<$type>.<$id>.keyring。
/etc/ceph/ceph.keyring ：命名格式为 ：/etc/ceph/<$cluster>.keyring。
/etc/ceph/keyring。
/etc/ceph/keyring.bin。

如果不存在这四个文件，或者在这四个文件里面均没有保存用户 client.admin 的秘钥，那么就会报错：ERROR: missing keyring也就是说，用户client.admin 登陆 Ceph 系统失败！

谁才是 CephX 中的鼻祖？

隐藏Boss 之 mon

一段对话：
client.admin : 当然是我！用我的账户密码登陆 Ceph 后可以执行任何指令!
mon. : 哦。
client.admin : 你谁？我这有所有账户密码(悄悄得查了下 ceph auth list)，怎么没看到你？
mon. : 嗯。
client.admin : 哎呀，哪个二货把我的秘钥文件删了，我不能连接集群了！
mon. : 让一让，我来帮你把秘钥找回来。
client.admin : 你？确定？
mon. : 嗯。

一直以为自己权限很大的client.admin，忽然因为丢失了保存密码的秘钥文件而不能访问集群了。而从未露面的 mon. 却号称能够找回 client.admin 的秘钥，难道说 mon. 才是真正的鼻祖？！
现在我们回到故事最初的起点，也就是集群搭建之初，我们使用 ceph-deploy new NodeA NodeB NodeC后，生成了三个文件：

ceph.conf
ceph.mon.keyring
ceph-deploy-ceph.log

除了ceph.conf ，还默认生成了一个 ceph.mon.keyring 文件，不出意外的话，这个文件几乎是不会在后面的集群交互中使用的，因为在 ceph-deploy mon create-initial 之后，会生成client.admin用户，而后面的交互一般都会使用这个用户了。但是集群生成的第一个用户却是<mon.> ，对应的秘钥文件保存在部署目录下的 ceph.mon.keyring。
查看 ceph-deloy 的 LOG，可以看到在步骤 ceph-deploy mon create-initial 时，有一段日志记录如下：

[2017-07-28 16:49:53,468][centos7][INFO ] Running command: /usr/bin/ceph --connect-timeout=25 --cluster=ceph --admin-daemon=/var/run/ceph/ceph-mon.centos7.asok mon_status
[2017-07-28 16:49:53,557][centos7][INFO ] Running command: /usr/bin/ceph --connect-timeout=25 --cluster=ceph --name mon. --keyring=/var/lib/ceph/mon/ceph-centos7/keyring auth get client.admin
[2017-07-28 16:49:53,761][centos7][INFO ] Running command: /usr/bin/ceph --connect-timeout=25 --cluster=ceph --name mon. --keyring=/var/lib/ceph/mon/ceph-centos7/keyring auth get client.bootstrap-mds
[2017-07-28 16:49:54,046][centos7][INFO ] Running command: /usr/bin/ceph --connect-timeout=25 --cluster=ceph --name mon. --keyring=/var/lib/ceph/mon/ceph-centos7/keyring auth get client.bootstrap-mgr
[2017-07-28 16:49:54,255][centos7][INFO ] Running command: /usr/bin/ceph --connect-timeout=25 --cluster=ceph --name mon. --keyring=/var/lib/ceph/mon/ceph-centos7/keyring auth get-or-create client.bootstrap-mgr mon allow profile bootstrap-mgr
[2017-07-28 16:49:54,452][centos7][INFO