FPs

Docker与虚拟机等的SSH权限管理控制解决方案

Docker和VM一类的云平台的权限控制如果采用常见的方式,把登录者的公钥写入~/.ssh/authorized_keys, 由于企业内部的人员流动和权限变更,往往不是十分便利。 特别是如果还选择把authorized_keys 打到镜像中的话,管理起来就会十分蛋疼。不过对于Docker这种容器,如果还需要开发登录进去进行Debug或者做其他操作的话,姿势上其实是不对的,不符合它的设计哲学,但是按照目前接触的国内使用Docker做内部云的厂商来看的话,大都是把Docker当作一个轻量级的VM来用而已,很多更是为了用Docker而用Docker。
这是题外话,如果是在企业内部的Server(Docker的容器、VM以及物理机),应该选择公共帐号登录,而不是给每个开发者或者运维人员都开一个个人帐号上去搞,这样不仅会十分混乱,而且员工离职之类的还好带来不少“遗留问题”。
一种解决思路是通过一些配置管理工具来管理Server的authorized_keys,例如Puppet、SaltStack、Ansible等。不过这需要运维人肉编辑配置文件,而且权限这种东西变更很频繁,所以更进一步是在这些配置管理工具只是进行开发,提供一个Web 服务作为权限控制平台。
另外一种解决思路是通过OpenSSH的AuthorizedKeysCommand选项,调用一个脚本,从远程的服务取得授权登者的公钥,具体做法可以参考前面链接的文章。
这种方法有个问题,如果远端权限管理的服务宕机了,可能是一个Web 服务,MySQL Server或者LDAP,都将造成通过这种方式授权的用户无法登录,所以必须保证该服务的稳定性。
另外应该禁止掉root登录,因为AuthorizedKeysCommand是作用于所有用户,包括root用户。将所有权限放在一个“篮子“里的话,除了得保证这个篮子的稳定性,还有安全性。
通过开发定制化一个Web服务,可以做更多事情,例如控制帐号的有效期,权限的批量开通等等。

2015-11-26 Docker VM SSH AuthorizedKeys