作者简介:
前言本文内容大致分成四部分:
1、选择
那年,我们的集群规模有400多台服务器,部分是很稳定地,大家慢慢就忽略掉它了。突然有一天监控系统上发现一台边缘很老的服务器负载太高,影响了主站的稳定性。 我的第一反应就是让业务运维登陆上去处理,结果过了5分钟业务运维反馈说“密码错误”。因为我们有业务运维和系统运维区分,所以我让系统工程师去登录一下。 结果不幸的是,系统管理员反馈“这个服务器比我们所有的工程师都早出现在这个公司,大家都不知道他的密码”。这个时候就非常着急了,我们收到大量的用户投诉。一个本来五分钟就可以解决的问题,但是我们却花了两个小时。 最后我们开总结会的时候,大家都认定这个问题得必须重视了,业务的扩展非常快,我们不可能每一个服务器都记录一个帐号,我们需要有一套统一的身份认证。 2、最初的需求诞生了当我们还在使用 SSH 跟 SCP 的时候,每个员工只需要一个密码,不管是登陆生产环境还是测试环境。我更改密码的时候也立即生效,而且我不想让 SA 知道我的密码,这就是我们最初的需求。 明确了需求之后,我们就开始考虑选择什么工具合适。有一种方案很简单就是我们用一个配置管理工具把这个服务器上面的 shadow/passwd 文件管理起来。 但是这样很被动,我所有的操作都依赖于它,我很多的操作生效期都会受到影响。还有另一个解决方案就是身份认证系统,我们知道这个是人人一直在用的 Kerberos,还有 OpenLDAP 也是一个比较热门的,最后就是商业产品堡垒机。 而创业公司的我们认为成本是第一要素,毋庸置疑首选就是开源。究竟是选择 kerberos 还是 OpenLDAP 呢? 我们请教了一个以前用过这方面的大拿,他推荐使用 OpenLDAP,因为使用起来很简单,就是用账户密码登陆。而 Kerberos 他可能会比较复杂一些,因为它有 Ticket 的认证过程。 所以我们就初步选择 OpenLDAP 了。同时我们发现国外的大厂 Facebook 和 谷歌都要使用 OpenLDAP,这就给了我们很大的信心。 同时,我们与商业产品进行对比,主要是价格和功能上有大的差异。
3、如何实施 OpenLDAP我介绍一下 OpenLDAP,它是轻量级目录访问协议,它特别适用于查询多但写入少的场景,可以做到毫秒级响应,但是如果是变更多的场景就不合适了。 然而它是怎么工作的呢?我们需要在需要认证的服务器上安装一个 OpenLDAP 的客户端,这个客户端其实是系统级别就已经是绑定了,我们就从这个图来看,我们是首先处于左下角。 用户登陆的时候,先登陆第一台跳板机,登陆上去的时候,其实访问的是本地的 PAM 模块,他通过 nsswitch 模块访问调用两个文件 passwd |
|
声明:文章版权归原作者所有 部分文章转自互联网 如有侵权请联系
[邮箱地址] 删除
|