许颖维，曾经就职于日PV超亿次的WAP搜索公司，后加入多次占领Facebook日活跃Top 10的游戏公司（产品有开心水族箱、开心消消乐），负责搭建自动化运维平台。 现任国内领先的商用车联网公司担任系统支持部负责人，同时负责实时在线并发车机百万级别的车联网平台运维工作。

前言

本文内容大致分成四部分：

选择，我们初步选择的时候会考虑哪些问题。

需求分析，分析我们的主要需求是什么，如何与服务进行紧密结合。

如何实施，因为运维人员比较关注工具的落地过程，所以我也重点讲讲这块，但是不会像很多文章一样讲详细部署过程，我会着重分享部署过程中容易出错的地方。

演变历程，以我在这家公司的经历为例，从一个最简单的需求发展到能够满足不同业务的需求，并最终满足比较苛刻安全的一个过程。

1、选择

整个故事要从一台老旧的服务器开始

那年，我们的集群规模有400多台服务器，部分是很稳定地，大家慢慢就忽略掉它了。突然有一天监控系统上发现一台边缘很老的服务器负载太高，影响了主站的稳定性。

我的第一反应就是让业务运维登陆上去处理，结果过了5分钟业务运维反馈说“密码错误”。因为我们有业务运维和系统运维区分，所以我让系统工程师去登录一下。

结果不幸的是，系统管理员反馈“这个服务器比我们所有的工程师都早出现在这个公司，大家都不知道他的密码”。这个时候就非常着急了，我们收到大量的用户投诉。一个本来五分钟就可以解决的问题，但是我们却花了两个小时。

最后我们开总结会的时候，大家都认定这个问题得必须重视了，业务的扩展非常快，我们不可能每一个服务器都记录一个帐号，我们需要有一套统一的身份认证。

2、最初的需求诞生了

当我们还在使用 SSH 跟 SCP 的时候，每个员工只需要一个密码，不管是登陆生产环境还是测试环境。我更改密码的时候也立即生效，而且我不想让 SA 知道我的密码，这就是我们最初的需求。

明确了需求之后，我们就开始考虑选择什么工具合适。有一种方案很简单就是我们用一个配置管理工具把这个服务器上面的 shadow/passwd 文件管理起来。

但是这样很被动，我所有的操作都依赖于它，我很多的操作生效期都会受到影响。还有另一个解决方案就是身份认证系统，我们知道这个是人人一直在用的 Kerberos，还有 OpenLDAP 也是一个比较热门的，最后就是商业产品堡垒机。

而创业公司的我们认为成本是第一要素，毋庸置疑首选就是开源。究竟是选择 kerberos 还是 OpenLDAP 呢？

我们请教了一个以前用过这方面的大拿，他推荐使用 OpenLDAP，因为使用起来很简单，就是用账户密码登陆。而 Kerberos 他可能会比较复杂一些，因为它有 Ticket 的认证过程。

所以我们就初步选择 OpenLDAP 了。同时我们发现国外的大厂 Facebook 和 谷歌都要使用 OpenLDAP，这就给了我们很大的信心。

同时，我们与商业产品进行对比，主要是价格和功能上有大的差异。

价格方面：一个机房我只要一台服务器，甚至是半台就可以搭建 OpenLDAP 服务，大约成本不到2万，而这个商业的堡垒机需要将近20万的成本。

架构模式： 差不多，一个 CS 一个 BS。

授权模式： 就是我们在对用户的权限管理方式，商业会比较有优势，这方面考虑的还是不错。还有操作回放是商业比较好的一个特征，因为他们支持这种审计功能，他们知道每一个用户登陆上去都在做什么。

但是后面这个开源也有，我们是通过 命令，就是可以把一个用户所有的操作包括回显都可以记录。这个还是挺不错的。

最主要的就是价格，老板说 OK 就可以了，毕竟老板对钱都是非常敏感的。

3、如何实施 OpenLDAP

我介绍一下 OpenLDAP，它是轻量级目录访问协议，它特别适用于查询多但写入少的场景，可以做到毫秒级响应，但是如果是变更多的场景就不合适了。

然而它是怎么工作的呢？我们需要在需要认证的服务器上安装一个 OpenLDAP 的客户端，这个客户端其实是系统级别就已经是绑定了，我们就从这个图来看，我们是首先处于左下角。

用户登陆的时候，先登陆第一台跳板机，登陆上去的时候，其实访问的是本地的 PAM 模块，他通过 nsswitch 模块访问调用两个文件 passwd & shadow，但是里面还有一个是可以支持多源的权限访问方式。

可以调动 OpenLDAP 的客户端，把帐号和密码发送给 OpenLDAP 服务器端（右下角的那台服务器），如果再 OpenLDAP 服务器端匹配正确，就返回给所登陆的服务器【OK】，这时我们就可以顺利的登陆服务器，这个是和使用正常登陆方式一模一样的。

OpenLDAP 记哪些信息，包括用户ID用户帐号，用户密码，包括权限的定义。这里涉及到提权的过程，因为我们每个人在有了 LDAP 账号之后，登陆到服务器上都是个人账号，而大部分的时候我们是有切换到其他账号需求的。

OpenLDAP 的提权管理做的比较强，它是 Sudoers schema 里面去定义每一组的具体权限，而每个人又对应到某个具体组内。这就能轻松做到我和这个组里的人权限一致，同时权限的变更是全局性的，所有服务器生效。

回顾最初需求

我们回顾当时最初的需求，并不是要做精细化管理，即只需要所有的人登录到服务器上，完成人员的账号认证，研发人员、运维都是个人用户，登陆上服务器之后使用 sudo 切换到 root 的 账号。

当时是用这种非常粗放的管理方式，当然我们数据库不在这个管理范围之内，因为这种OpenLDAP登陆数据库太危险了，不建议使用它们来管理数据库。

接下来是安装过程，（在这里就不细写了我着重讲客户端的配置过程）

我使用 authconfig-tui 命令就可以进入到这个模式，这个配置很简单，只要前面勾选五个选项，然后下一步把 URI 和 Base 配置完成就 OK 了。

但是运维关注的是，这些操作的背后究竟是做了什么事情。如果我操作完还不生效就需要去查看配置文件。其中包括这么几个配置文件：

1. /etc/ldap.conf

2. /etc/nsswitch.conf

3. /etc/sysconfig/authconfig

4. /etc/pam.d/system-auth

只要保证这些配置文件按要求进行修改，不用使用交互式工具也可以完成配置过程。

完成配置之后我们就会经常收到其他同事的抱怨，误操作删除掉系统文件，压力好大。接下来我们就开始了权限的精细化管理演变。

4、演变历程4.1 精细化管理

上面就是权限的精细化管理的成员类别逻辑图：

第一级为系统管理员；

第二级就是应用运维，他能够做服务的变更；

第三级就是网络管理员，他能做执行一些命令操作，因为我们最担心是网络管理员以“权限不够”为名，让系统工程师干活。因此我们就给他增加了一些权限；

第四级就是 observer 这个角色，这个就是给研发用的，研发有需求看日志但是不能有操作权限的；

最后一个就是 Personal，这个就是个人，用于证明你就是你。

还有一个图非常重要，就是要跟大家讲一个普遍新手都会误会的地方，大部分人认为在 OpenLDAP 管理内，首先就是组，然后下面的分支是人，再下面的分支是权限。其实不是这样的，如下图：

其实人、组、权限都是并列的，具体而言，在这个人属性里面包含了一个元素 UID，如果五个人对应同一个 UID，那这五个人就是一个组。

权限分支内定义很多的权限组，权限组又有属性和组对应，因此人跟组、权限就对应起来了，所以大家看书的时候不要被误导了，这个就是落地的基本形式。

4.2 分布式管理

接下来问题来了，我们是一个车联网的公司，全国有将近十个机房，我们需要考虑这么多个机房的部署和维护工作。

最简单是我们所有的服务器都到一个地方认证，看似很棒的一个方案，但其实你想，这是不行的。因为我们很多时候有登陆服务器的紧急需求就是网络故障或者是普通服务故障。

如果是集中式管理，可能会导致网络有故障的时候服务器认证也有问题。所以解决方案是分布式管理，分布式认证。

这个跟 MysqlCluster 集群的管理方式是一样的，有 Master 节点负责写入，通过日志推到各个机房的 Slave 上面，然后在本地进行 redo 到 Slave 上。

同时所有的用户都是在本机房内的节点进行认证，所有的修改会被 rewrite 到 Master 节点上。下图就是具体日志，我们可以看看里面的描述：

这个就是在几点几分的日志，就是他把这个用户的密码改了。目前我们能做到七百台服务器同时并发登陆及更改密码，基本上公司大部分的需求我们都可以满足。

4.3 安全考虑

本以为完成全部的需求，这时候安全部门找到我们，质疑我们“你们这个东西安全吗？你们目前的安全状况确实是太糟糕了，所有用户的登陆过程密码我全部都看见了”......

这确实是太糟糕了，在我的经验里面，上线不到几小时就发现从马来西亚不断的有尝试暴力破解我们的服务器的情况，一旦尝试暴力破解成功所造成的影响是超过我们预期的。这样，我们就开始了安全方面的需求改造。

非常庆幸的是 OpenLDAP 支持 TLS 的证书认证方式。这里有一个建议，就是大家做证书的时候一定要使用泛域名证书。为什么？

因为你可能涉及到每一个组机房都使用唯一的一个域名。你所有的机房都可以使用同一个证书，因为你不用管哪一个机房都可以使用泛域名证书。

同时我们还做了限制登录的方案，这个跟 OpenLDAP 没有关系。只是我们使用 PAM 模块对登录失败用户进行限制而已。

只要单个用户五次登陆失败，锁定600秒这个大家可以试一下。

4.4 服务解耦

安全部门也搞定了，最后一个问题就是服务解耦。为什么会有这个需求呢，因为有一天运维反馈所有的服务器登录特别慢，是因为在 Nginx 上面，起用了新功能，需要读本地的文件。

而我们知道每一次读本地文件的时候，就需要检查这个用户是不是有权限，很不幸他把所有的权限校验过程都发给了 OpenLDAP 服务器，我们当时的用户是每秒钟有七千个用户访问，我们的服务器感觉快爆了。

我们看了一下这个 OpenLDAP 的官网，其实已经给我们解决相关的办法，解决这个问题需要在客户端的 /etc/ldap.conf 文件里面增加nss_initgroups_ignoreusers 参数，就是说这些用户统统都不用去做认证，只需要去做本地的 Passwd 和 Shadow 里面即可，这样就解决完成解耦的问题。

4.5 对个人账号基于服务器的限制

后续又有项目组的领导说，我们现在服务器比较多，但是我不想其他项目组看到我们的代码日志等信息，如何？

OpenLDAP 也是可以满足这个需求的，他可以使用 pam_check_host_attr这种参数来保证我可以做到每一个用户只能登陆我们指定的服务器，这里我就不详细说明，给大家点个方向。

4.6 内部需求：高效管理

我们到目前为止没有发生大问题的时候，但是发现公司不断的发展，人员的离职、入职及人员的变动经常需要我们进行账号的删除添加，这是我们内部管理的要求。

后来我们给自己开发了一个 web 管理系统，对添加删除账号转变成更为简单的操作。

这个就是把一个修改账号的请求通过 web 页面进行描述，将请求存储到数据库内，并在后端使用定时任务将其操作内容在 OpenLDAP 内进行生效，并返回给他结果的过程。最终体现在页面上就是这样。

4.7 整个系统的发展

回顾一下我们整个系统的发展阶段：

第一个就是帐号密码管理；

第二个就是方案架构的方面的调整；

第三个安全我们做了主机的限制，还要做了防暴力破解；

第四个就是高效管理，应对内部的管理需求；