避免让持续集成服务器成为一个安全隐患!

简介:

背景

最近临时接手了一个客户测试环境和产品环境的维护工作。接手的客户资产里包含:代码库,生产环境主机,测试环境主机以及搭建在测试环境主机上的CI(基于Jenkins)。这个CI可以用来部署测试环境和生产环境的应用。

不久,接到了客户的一个维护请求:把最新的生产环境数据同步到测试环境里。

这个维护工作需要通过SSH登录到测试环境主机上进行操作。测试主机是通过authorized_keys进行 SSH 认证的,因此没有用户名和密码。这样有两个好处:一方面无需生产环境用户名密码。一方面可以按需吊销不再用的客户端。这样可以避免密码泄露。所以我需要把自己的ssh public key交给管理员,让他把我的 key 加到可访问列表里。

悲剧的是,管理员告诉我他的 key 因为更换电脑的关系没有及时更新。所以,他也登录不上去了。而且之前所有的管理员的 key 都失效了。我手上只有CI的管理员的用户名和密码,于是一个邪恶的想法就诞生了:

既然 CI 可以执行脚本,那么我是否可以通过CI把我的key注入进去?

于是我用Execute Shell的Job变成了我的命令行,通过CI运行日志得知了宿主用户的文件目录信息。然后把自己的ssh public key加到了登录列表里(此处省略敏感信息):

 
 
  1. sudo sh -c “cp ~/.ssh/authorized_keys ~/.ssh/authorized_keys.bak” 
  2. sudo sh -c “echo ‘{你的ssh public key}’ >> ~/.ssh/authorized_keys” 

It works !

我成功的登录了机器,但这却暴露了一个问题:CI 有可能会成为一个安全隐患。

首先,CI 可以执行代码。这就意味着它有可能执行有害代码。

其次,CI 缺乏足够的用户鉴权,这很有可能导致未授权用户访问。

那么,如何构建一个更安全的CI服务器?

rootless原则

“神操纵着万物,你感觉得到他,但永远看不见他。” ——《圣经·希伯来书11:27》

在服务器的世界里,root用户就是神,具有至高的权力和力量。如果有人获得了”神力“,后果可能不堪设想。

无论是Web服务器,还是CI服务器。都是这个世界里的二等公民,权限和力量都应该受到约束。执行的时候应该“

此外,应该极力避免sudo的滥用,尤其是对那些从外部访问的用户。很多情况下,为了操作方便,很多用户都有sudo的权限。但这恰恰造成了低权限用户提升自己的访问权限进行有害操作。

在上述的故事里,因为没有对Jenkins的主机用户做有效的隔离,导致了我可以用sudo注入自己的key获得机器的访问权限。

沙盒隔离原则

因为CI会执行脚本或运行程序,而这些程序和脚本极有可能是不安全的。所以,CI任务应该在隔离的安全沙盒中执行,例如:受限的用户,受限的权限,受限的空间。

在上述的故事里,我就通过CI执行了一段不安全的脚本成功获得了登录主机的权限。

如果这些任务执行在隔离并受控的Docker容器里,那么会安全得多。

也可以考虑采用TravisCI这样的第三方CI服务来保证安全性。

备份和备份核查原则

在上述的故事里,因为缺乏有效的备份机制,导致了所有人都失去了对主机的访问。此外,我在修改authorized_keys的时候先进行了备份。这样,如果我注入失败,还可以还原。

这里的备份,不光是对配置,数据的备份,还有岗位的备份。

如果有备份的管理员,完全不会出现这种事情。

如果有备份QA服务器,完全可以不需要当前的QA服务器。

在做任何变更前,都应该做好备份以及还原的准备。因为任何变更都会带来“蝴蝶效应”。

但是,光备份是不够的。如果备份不能有效还原,那和没有备份没有什么区别。所以,要定时的进行备份恢复测试。确保备份在各种情况下可用。

多重要素身份验证原则

上述的CI是暴露在互联网中的,任何一个人访问到这个站点,通过一定程度的密码破解,就可以获得这个CI的访问控制权限。从而可以做出上述的操作。

所以,有了用户名和密码,并不一定是可信用户。所以需要通过更多的手段,诸如手机短信验证码或者第三方认证集成来验证用户的身份。

关键操作手动验证原则

试想一下,如果上述的例子我并没有服务器的访问权限。而是通过提交未经审查的代码自动运行测试脚本。实际上也会造成同样的效果。

有时候我们会为了方便,让CI自动触发测试。但是,恰恰是这种“方便”,却带来了额外的安全隐患。而这样的方便,不光方便了自己,也方便了恶意入侵者。

所以,不能为了方便而留下安全隐患。在关键操作上设置为手动操作,并通过一定的机制保证关键操作的可靠性才是最佳实践。

构建安全CI 的几个实践

采用Sibling的方式在Docker里运行CI任务。

账户密码管理统一采用LDAP认证,如果过期则从外部修改。

CI的登录权限和其它的认证方式(比如GItHub,Okta等)集成起来。并用组限制登录。

对于生产环境的CI,通过更加细粒度的权限限制来隔离一些危险操作。


本文作者:顾宇

来源:51CTO

相关文章
|
1月前
|
SQL 弹性计算 安全
购买阿里云活动内云服务器之后设置密码、安全组、增加带宽、挂载云盘教程
当我们通过阿里云的活动购买完云服务器之后,并不是立马就能使用了,还需要我们设置云服务器密码,配置安全组等基本操作之后才能使用,有的用户还需要购买并挂载数据盘到云服务器上,很多新手用户由于是初次使用阿里云服务器,因此并不知道这些设置的操作流程,下面给大家介绍下这些设置的具体操作流程。
购买阿里云活动内云服务器之后设置密码、安全组、增加带宽、挂载云盘教程
|
2月前
|
弹性计算 人工智能 安全
带你读《从基础到应用云上安全航行指南》——阿里云产品专家教你如何全方位构建ECS安全体系(3)
带你读《从基础到应用云上安全航行指南》——阿里云产品专家教你如何全方位构建ECS安全体系(3)
432 0
|
2月前
|
存储 弹性计算 安全
带你读《从基础到应用云上安全航行指南》——九大提升ECS实例操作系统安全性的技巧(1)
带你读《从基础到应用云上安全航行指南》——九大提升ECS实例操作系统安全性的技巧(1)
335 1
|
2月前
|
弹性计算 安全 网络安全
带你读《从基础到应用云上安全航行指南》——阿里云产品专家教你如何全方位构建ECS安全体系(2)
带你读《从基础到应用云上安全航行指南》——阿里云产品专家教你如何全方位构建ECS安全体系(2)
478 0
|
2月前
|
存储 弹性计算 安全
带你读《从基础到应用云上安全航行指南》——九大提升ECS实例操作系统安全性的技巧(2)
带你读《从基础到应用云上安全航行指南》——九大提升ECS实例操作系统安全性的技巧(2)
662 1
带你读《从基础到应用云上安全航行指南》——九大提升ECS实例操作系统安全性的技巧(2)
|
5天前
|
缓存 安全 调度
代理服务器如何保护用户隐私和安全?
Python搭建代理IP池实现接口设置与整体调度
22 10
|
13天前
|
弹性计算 安全
电子好书发您分享《阿里云第八代企业级ECS实例,为企业提供更安全的云上防护》
阿里云第八代ECS实例,搭载第五代英特尔至强处理器与飞天+CIPU架构,提升企业云服务安全与算力。[阅读详情](https://developer.aliyun.com/ebook/8303/116162?spm=a2c6h.26392459.ebook-detail.5.76bf7e5al1Zn4U) ![image](https://ucc.alicdn.com/pic/developer-ecology/cok6a6su42rzm_f422f7cb775444bbbfc3e61ad86800c2.png)
35 14
|
26天前
|
弹性计算 DataWorks 关系型数据库
ECS安全组问题之加入多个安全组如何解决
ECS(Elastic Compute Service,弹性计算服务)是云计算服务提供商提供的一种基础云服务,允许用户在云端获取和配置虚拟服务器。以下是ECS服务使用中的一些常见问题及其解答的合集:
|
2月前
|
弹性计算 运维 安全
阿里云轻量应用服务器:一款高效、稳定、安全的云计算服务
阿里云服务器ECS和轻量应用服务器有什么区别?轻量和ECS优缺点对比,云服务器ECS是明星级云产品,适合企业专业级的使用场景,轻量应用服务器是在ECS的基础上推出的轻量级云服务器,适合个人开发者单机应用访问量不高的网站博客、云端学习测试环境等,阿里云服务器网从从使用场景、适用人群、计费方式、系统镜像、网络带宽、运维管理等多方面来详细说下二者区别及如何选择
96 1
|
2月前
|
弹性计算 安全 网络安全
带你读《从基础到应用云上安全航行指南》——阿里云产品专家教你如何全方位构建ECS安全体系(1)
带你读《从基础到应用云上安全航行指南》——阿里云产品专家教你如何全方位构建ECS安全体系(1)
427 0