背景介绍最近，笔者接手了公司的一个任务：搭建服务器的堡垒机跳板机。关于跳台机的实现，网上其实有很多简单的版本，甚至还有开源的堡垒机Jumpserver可以选择。有很多解决方案。接下来，我会整理几篇文章，对我的实施方案做一个简单的说明。覆盖功能正所谓兵马未动，粮草先行。在设计之前，我们先梳理一下堡垒机一期会涉及到的基本功能点：服务器统一账号权限管理，包括哪些用户可以登录哪些服务器，哪些用户有sudo权限；用户行为记录，必要时可查阅、查阅；用户登录验证审核；最初的目标是通过堡垒机管理和控制所有的linux服务器。以后也可以通过ssh协议访问交换机，路由器，甚至Windows进行管理（目前Windows已经可以通过ssh登录，但是这种方式没有图形界面，只能通过powershell进行管理）。架构设计基于以上功能点，设计架构如下：下面是对这张架构图的解释：整体分为三层。一般来说，第一层验证用户是否有权限登录堡垒机；第二层实际上是给用户分配权限，同时判断通过***层的用户是否有操作目标机器的权限；第三层是实际登录/操作服务器的方式。这里我通过ldap通过服务器的auth+sudo权限来进行分布式动态管理，后面会有专门的说明；***层：登录入口，任何有堡垒机使用权限的人都可以从这个入口登录成功。涉及的主要服务：用户登录shell。服务主要功能：读取用户信息，判断是否有登录权限；调用动态令牌服务来验证用户密码；调用动态token服务实现扫码快速登录；在第二层调用授权服务api获取&判断用户的登录权限；记录用户操作日志；associatedservices：动态Token服务，类似googleauth，每个人的动态密码不同，每分钟更新一次，用于验证登录堡垒机，当然如果你想要简单，可以单独分配一个静态密码；第二层：授权服务管理，获取登录用户当前授权ip列表，判断用户操作是否符合预授权。涉及的主要服务：权限管理服务服务主要功能：设置用户/团队权限列表；向三层ldap集群发送权限数据；提供api获取用户权限列表；关联服务：CMDB，在cmdb中以服务树为授权的基本单元，同时在cmdb中判断授权的服务器对象是否有效；OA，以oa中的用户组作为授权的基本单位，根据oa判断用户是否有效；第三层：登录实体服务器&执行命令；将所有目标服务器的ssh登录系统连接到ldap集群，并在ldap中设置用户的publickey&sudo等信息，统一控制用户的登录权限&sudo权限。目标规模：使用两台服务器做一个ldap主从集群，所有物理服务器都连接到这个集群上，统一进行auth验证。未完待续整体架构描述就这么简单，接下来给大家分享一下每一层的具体实现。
