社区分享｜资深开源用户眼中的JumpServer：一款“疯狂”迭代的堡垒机

编者注：2022年1月，JumpServer开源社区访谈了来自广州的开源社区资深用户刘哲，以下内容根据本次访谈的内容整理而成。

“作为一个JumpServer开源堡垒机的资深用户，我一直都在关注JumpServer项目的技术演进情况。过去的几年时间里，JumpServer呈现出近乎‘疯狂’的迭代速度。”

                  ——JumpServer开源项目资深用户 刘哲

作为一位开源技术的爱好者，我从事IT运维的工作多年，在不同行业的公司都做过运维方面的工作，对新技术，尤其是开源技术也非常感兴趣。目前我主要负责的是DevOps运维方面的工作。

最早接触到JumpServer开源项目是在2017年。从当时的v0.4.0版本到现在使用的v2.17.0版本，我一直都是JumpServer的忠实粉丝，深入研究过JumpServer，也持续跟随着JumpServer的脚步不断地升级新版本、使用新功能，并且使用JumpServer堡垒机成功地为所服务的公司建立了规范的运维安全审计系统。

为什么会选择JumpServer？

最早的时候我当时工作的公司使用的是传统的跳板机，是通过在Windows上搭建服务，用户开启远程桌面服务的方式来进行操作的。这种应用模式存在一些明显的短板，具体表现在以下几方面：

缺乏录像审计

由于跳板机是没有审计功能的，所以我们交付给开发、测试同事的环境没有操作过程的记录，并且对高危命令、上传/下载的管控存在漏洞，这就导致了一旦出错后需要花费大量的时间来排错。我们在使用过程中遇到过很多次类似的问题，当时还遇到过代码泄露、服务器宕机等事故，这些意外事件的发生触发了公司寻找跳板机替代方案的需要；

运维效率低下

随着企业IT规模的不断扩大，IT资产的体量也迅速膨胀，加上未来基础设施的持续投入和发展，设备数量也会继续增长。因此，如何实现对大规模资产的高效管理成了运维管理的重点工作之一；

安全审计的需要

之前我们在一台资产上保存了大量的用户密码，这就产生了很大的安全隐患，公司对于安全审计的需求逐渐提升。同时，随着IT系统运维对堡垒机依赖程度的不断增加，系统稳定运行的重要性也不断地攀升，这就需要对用户操作所产生的大量审计资料进行有效存储，并随时可以提取回溯。

毫无疑问，堡垒机对于运维人员来说是一个非常关键的工具，大部分企业的运维人员都会首选堡垒机来进行资产的管理和接入。

基于以上痛点问题和实际需求，我们急需找到一款堡垒机去替代跳板机来进行日常的运维安全管理。

作为一个开源爱好者，我偶然间在GitHub上找到了JumpServer开源项目，发现它在功能层面能够满足我们的主要需求，比如录像审计、资产录入、密码代填等功能，并且完全可以覆盖到我们常用的一些使用场景。

以下四点我认为是JumpServer比较具有吸引力的地方：

■ 好用：JumpServer简单易用，没有技术门槛，非常容易上手，对于那些没有技术基础的用户十分友好。同时，这种易用性也让技术人员能够花费更少的时间成本来学习堡垒机的使用技能；

■ 开源：JumpServer提供了一个开放、兼容的平台，用户基数大，让更多像我一样的开源用户相互沟通进步，共同参与到安全管理的生态中来；

■ 安全：JumpServer符合4A规范，能够满足企业运维安全审计的实际要求；

■ 用户体验极佳：用户访问JumpServer的时候能够享受到简洁的使用界面，无需插件，很大程度提升了用户的使用体验。

JumpServer的使用经验

算起来我个人使用JumpServer开源堡垒机也有将近五年的时间了，也积累了相对丰富的使用经验。总结过去几年的使用体验，JumpServer以下的几个核心功能能够切实提升企业的运维管理能力：

■ 操作审计功能

我们进行系统交付、故障处理、日常巡检等工作的时候，往往需要一些后端同事、合作伙伴或者运维外包人员登录资产来进行操作。这样一来，可能会出现人员不熟悉操作或者误操作的情况，从而引发一些系统故障，我们经常会发现各种因环境临时变更而导致的问题。发生这种情况后，运维团队就需要溯源整个操作过程，定位具体原因。

通过JumpServer，我们可以对所有的操作进行录屏录像、记录操作命令，并且作为审计依据进行保存。同时，管理员或者运维负责人还可以对操作进行实时监控，一旦发现违规操作，立即中断操作。即使是发生了系统故障问题，也可以根据审计录像快速定位故障原因，无需花费过多的时间去验证。这也是我们认为JumpServer最为核心的一个功能。

在这里插入图片描述

                图1 操作审计场景

■ 用户管理和授权控制功能

通常情况下，企业会根据两个维度来进行授权控制，分别是以用户及用户组为核心维度和以资产为核心维度。相信大多数的公司都会以用户组来区分授权，以便于管理。

由于我们公司有不同的项目组，需要授权不同的资产，因此我们选择的是“以资产为核心维度”进行授权控制，将不同用户账户加入不同权限用户组授权访问单台设备。

在这种情况下，我们的一台数据库需要三种权限：第一种权限是针对后端同事的读写权限；第二种是针对测试同事的只读权限；第三种是针对运维人员的高级权限，也就是管理权限。通过数据库本身的账号权限给予权限后，再通过JumpServer用不同的账号分发下去，这就很好地实现了更细粒度的资产授权管理。

在这里插入图片描述

             图2 不同维度授权方式对比

■ 密码代填功能

密码代填也是我们使用得比较多的功能，目前我们所有的资产都已经实现了资产密码代填。

以前，我们所有人员都是共同使用相同的账号密码登录到资产来进行运维管理与操作。因此，每当遇到高危命令、数据误删等事故时，就很难定位到具体的操作人，无法进行责任的认定与相应的故障分析。部署JumpServer之后，每一个用户都会分配到一个账号，每个账号授权不同的资产登录权限。

同时，JumpServer托管了所有的资产密码，通过密码代填功能，我们不需要将密码给到用户，用户可以直接登录到资产进行操作。任何人通过JumpServer登录到资产，管理员都能很容易地查询出是谁在何时、用了什么账号登录了哪台资产？进行了什么样的操作？这样一来，很大程度上提升了系统和资产的安全性。

在这里插入图片描述

         图3 通过JumpServer实现密码托管

■ Kubernetes运维管理

Kubernetes的运维管理是我最为惊喜的JumpServer的功能之一，这也是JumpServer区别于其他堡垒机的一个亮点功能。我之前接触过很多其他品牌的堡垒机，它们都没有针对Kubernetes进行接入或管理，一般是通过RemoteApp的方式，在每个人的本地客户端安装一个kubectl的工具来实现的，非常麻烦。

而通过JumpServer堡垒机来应对日常Kubernetes运维管理任务就非常方便。在Kubernetes上配置好RBAC（Role-Based Access Control，基于角色的访问控制权限）并进行授权，就可以直接连入集群，一步到位，非常便捷。

目前我们是有4个集群在使用这个功能，比如日常的台账都是通过Kubernetes去接入的，这样就可以随时随地、更加快捷地去进行操作，方便了运维操作，提升了整体的安全性。

我们公司的生产环境，包括微服务框架，都是部署在Kubernetes上的，Kubernetes已经成为我们主流的部署方式。因此，我们非常注重JumpServer对Kubernetes部署场景的支持，这也有利于我们全面推行容器化部署，进行横向扩展。

JumpServer亮点功能

除了以上几个核心功能以外，还有一些我比较欣赏的JumpServer亮点功能想要跟大家分享一下：

■ 安装部署方便，一键即可完成部署、升级，操作简单；

■ 支持MFA二次认证等多种认证方式，支持水印、多种密码策略，提升了安全性；

■ 支持录像文件上传至公有云对象存储等功能，实用且安全；

■ Web界面实现文件上传/下载功能；

■ 从用户角度考虑，支持终端自定义设计，让用户可以根据自己的喜好去设置，非常贴心。

对JumpServer的期望与建议

最近几年，JumpServer开源项目呈现出了一种近乎“疯狂”的迭代速度，这种“疯狂”是用户所乐见的。JumpServer项目每个月的更新日志我都有认真去看，每一次新版本都会增加很多新的功能，功能越来越完善，更加贴合用户的需求，带给了我非常多的惊喜。

长期从事运维的相关工作，我对传统的堡垒机也有所了解，也拥有实际使用的经验。有些品牌的堡垒机在易用性上做得非常好，也很符合当时用户的使用习惯。比方说直接去调用本地的终端，类似于XShell等；比方说一些堡垒机在很早期就提供类似于RemoteApp的功能，支持的应用类型也比较丰富。

从我的角度看，JumpServer的优势在于它一直保持着高速迭代的状态。整个开源社区的活跃度非常高，对社区用户的需求响应速度也很快。这些都让JumpServer有了“超越”的可能。像是会话共享的功能，有的堡垒机在2018年就发布了这个功能，JumpServer在v2.14.0版本也实现了这个功能。

从某种程度来说，这不是哪款产品比哪款产品好的问题，而是谁更贴近用户，谁更能适应用户需求的变化。每一个用户的使用场景都不一样，我之前所工作的公司没有容器化部署的需求，他们一直在使用传统的堡垒机。而我现在工作的公司有非常多的Kubernetes集群，JumpServer自然成为了堡垒机的首选。

最后说说我个人对JumpServer的一些期望，希望在未来能够看到JumpServer在以下三方面的优化：

■ 数据库场景

数据库场景是我们公司目前比较重度使用的一个场景。每个公司使用的数据库有所不同，我们主要的数据库场景有MySQL和微软的SQL Server，还在使用PostgreSQL来同步总公司的数据。

目前，JumpServer已经支持了多种数据库类型，包括MySQL、Redis，还有企业版支持的Oracle、PostgreSQL、MariaDB、SQL Server数据库应用授权，未来我们也期待着JumpServer能够支持纳管更多的数据库类型；

■ 优化RemoteApp功能

在JumpServer的RemoteApp上使用发布工具时，有些用户会认为不太方便。因为所有的代填、接入等操作都需要通过RemoteApp这个平台去连接。如果关闭窗口后，再次通过RemoteApp连接数据库开启新窗口，之前所操作的语句就无法找到，而且通过RemoteApp的方式没办法实现命令阻断。希望未来能够有更多关于RemoteApp功能的优化；

■ 权限控制的优化

JumpServer目前在需要获取资产设备状态时，要给用户比较大的sudo权限。从安全的角度考虑，我们不希望将那么大的权限给到用户去获取设备信息，所以希望未来JumpServer在这方面能够提供更加优化的解决方案。