中交兴路运维总监:中小企业如何优雅的管理多机房服务器账号
《中交兴路运维总监:中小企业如何优雅的管理多机房服务器账号》要点: 作者简介:
前言本文内容大致分成四部分:
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 & shadow,但是里面还有一个是可以支持多源的权限访问方式. 可以调动 OpenLDAP 的客户端,把帐号和密码发送给 OpenLDAP 服务器端(右下角的那台服务器),如果再 OpenLDAP 服务器端匹配正确,就返回给所登陆的服务器【OK】,这时我们就可以顺利的登陆服务器,这个是和使用正常登陆方式一模一样的. OpenLDAP 记哪些信息,包括用户ID用户帐号,用户密码,包括权限的定义.这里涉及到提权的过程,因为我们每个人在有了 LDAP 账号之后,登陆到服务器上都是个人账号,而大部分的时候我们是有切换到其他账号需求的. OpenLDAP 的提权管理做的比较强,它是 Sudoers schema 里面去定义每一组的具体权限,而每个人又对应到某个具体组内.这就能轻松做到我和这个组里的人权限一致,同时权限的变更是全局性的,所有服务器生效.
接下来是安装过程,(在这里就不细写了我着重讲客户端的配置过程) 我使用 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 精细化管理上面就是权限的精细化管理的成员类别逻辑图:
还有一个图非常重要,就是要跟大家讲一个普遍新手都会误会的地方,大部分人认为在 OpenLDAP 管理内,首先就是组,然后下面的分支是人,再下面的分支是权限.其实不是这样的,如下图: 其实人、组、权限都是并列的,具体而言,在这个人属性里面包含了一个元素 UID,如果五个人对应同一个 UID,那这五个人就是一个组. 权限分支内定义很多的权限组,权限组又有属性和组对应,因此人跟组、权限就对应起来了,所以大家看书的时候不要被误导了,这个就是落地的基本形式. 4.2 分布式管理接下来问题来了,我们是一个车联网的公司,全国有将近十个机房,我们需要考虑这么多个机房的部署和维护工作. 最简单是我们所有的服务器都到一个地方认证,看似很棒的一个方案,但其实你想,这是不行的.因为我们很多时候有登陆服务器的紧急需求就是网络故障或者是普通服务故障. 如果是集中式管理,可能会导致网络有故障的时候服务器认证也有问题.所以解决方案是分布式管理,分布式认证. 这个跟 MysqlCluster 集群的管理方式是一样的,有 Master 节点负责写入,通过日志推到各个机房的 Slave 上面,然后在本地进行 redo 到 Slave 上. 同时所有的用户都是在本机房内的节点进行认证,所有的修改会被 rewrite 到 Master 节点上.下图就是具体日志,我们可以看看里面的描述: 这个就是在几点几分的日志,就是他把这个用户的密码改了.目前我们能做到七百台服务器同时并发登陆及更改密码,基本上公司大部分的需求我们都可以满足. 4.3 安全考虑本以为完成全部的需求,这时候安全部门找到我们,质疑我们“你们这个东西安全吗?你们目前的安全状况确实是太糟糕了,所有用户的登陆过程密码我全部都看见了”…… 这确实是太糟糕了,在我的经验里面,上线不到几小时就发现从马来西亚不断的有尝试暴力破解我们的服务器的情况,一旦尝试暴力破解成功所造成的影响是超过我们预期的.这样,我们就开始了安全方面的需求改造. 非常庆幸的是 OpenLDAP 支持 TLS 的证书认证方式.这里有一个建议,就是大家做证书的时候一定要使用泛域名证书.为什么? 因为你可能涉及到每一个组机房都使用唯一的一个域名.你所有的机房都可以使用同一个证书,因为你不用管哪一个机房都可以使用泛域名证书. 同时我们还做了限制登录的方案,这个跟 OpenLDAP 没有关系.只是我们使用 PAM 模块对登录失败用户进行限制而已. 只要单个用户五次登陆失败,锁定600秒这个大家可以试一下. 4.4 服务解耦安全部门也搞定了,最后一个问题就是服务解耦.为什么会有这个需求呢,因为有一天运维反馈所有的服务器登录特别慢,是因为在 Nginx 上面,起用了新功能,需要读本地的文件. 而我们知道每一次读本地文件的时候,就需要检查这个用户是不是有权限,很不幸他把所有的权限校验过程都发给了 OpenLDAP 服务器,我们当时的用户是每秒钟有七千个用户访问,我们的服务器感觉快爆了. 我们看了一下这个 OpenLDAP 的官网,其实已经给我们解决相关的办法,解决这个问题需要在客户端的 ? 4.5 对个人账号基于服务器的限制后续又有项目组的领导说,我们现在服务器比较多,但是我不想其他项目组看到我们的代码日志等信息,如何? OpenLDAP 也是可以满足这个需求的,他可以使用 4.6 内部需求:高效管理我们到目前为止没有发生大问题的时候,但是发现公司不断的发展,人员的离职、入职及人员的变动经常需要我们进行账号的删除添加,这是我们内部管理的要求. 后来我们给自己开发了一个 web 管理系统,对添加删除账号转变成更为简单的操作. 这个就是把一个修改账号的请求通过 web 页面进行描述,将请求存储到数据库内,并在后端使用定时任务将其操作内容在 OpenLDAP 内进行生效,并返回给他结果的过程.最终体现在页面上就是这样. 4.7 整个系统的发展回顾一下我们整个系统的发展阶段:
原文来自微信公众号:高效运维 (编辑:李大同) 【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容! |