堡垒跳板机实现——整体架构
背景介绍
最近，笔者接手公司的一项任务：建造服务器的堡垒跳板机。
关于跳板机的实现，其实简单版本网上一大堆，甚至更有开源堡垒机Jumpserver可供选择，方案很多。接下来会就我的实现方案，整理出几篇文章来做概要描述。
覆盖功能
正所谓兵马未动，粮草先行，在设计之前，先整理出我们一期中堡垒机要覆盖的基本功能点：
服务器统一账号权限管理，包括哪些用户可以对哪些服务器进行login，哪些用户有sudo权限; 用户行为记录，可在必要时回看审查; 用户登录校验审查;现在初期的目标是将所有的linux服务器通过堡垒机进行管理把控，将来扩展下，同样可以通过ssh协议对 交换机、路由器、甚至是Windows进行管理(目前windows已经可以实现通过ssh登录，不过这种方式就没有图形界面了且只能通过powershell来进行管理)。
架构设计
基于以上几点功能点，设计架构如下：
下面对这个架构图做下说明：
整体分为三层，总体来说，
***层 校验用户是否有登录堡垒机的权限;
第二层真正为用户分配权限，同时判断经过***层的用户是否有对目标机器操作的权限;
第三层则是真正登录/操作服务器的方式，在这里我将服务器的auth+sudo权限通过ldap来进行分布式动态管理，稍后会有专门的说明;
***层：
登录入口，凡是有堡垒机使用权限的均可以由此入口处登录成功。
涉及主要服务： user login shell。
服务主要功能：
读取用户信息，判断是否有登录权限; 调用动态Token服务，验证用户passwd; 调用动态token服务，实现二维码扫码快速登录; 调用第二层中的授权服务api，获取&判断用户的login权限; 记录用户操作日志;关联服务：
动态Token服务，类似于google auth，每个人的动态码均不一样，每分钟update一次，以此做登录堡垒机的校验，当然如果想简单，单独分配一个静态密码也可以;第二层：
授权服务管理，获取登录用户当前的权限ip列表，判断用户的操作是否符合预授权。
涉及主要服务：授权管理服务
服务主要功能：
设置用户/team的 权限列表; 将权限数据下发至第三层的ldap集群; 提供api获取用户的权限list;关联服务：
CMDB，以cmdb中的服务树为基本单位做授权，同时在cmdb中判断授权的服务器对象是否有效; OA，以oa中的用户组为基本单位做权限授予，同时基于oa来判断用户是否有效;第三层：
登录实体服务器&执行命令;
将所有目标服务器的ssh登录体系对接ldap集群，通过在ldap中设置用户的publickey & sudo等信息，来统一控制用户的登录权限&sudo权限。
目标规模：使用两台服务器做ldap主从集群，所有实体服务器对接此集群，从而统一进行auth验证。
未完待续
整体的架构说明就简单这样，接下来对就每一层的具体实现在分别和大家分享。
