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

背景

最近临时接手了一个客户测试环境和产品环境的维护工作。接手的客户资产里包含:代码库,生产环境主机,测试环境主机以及搭建在测试环境主机上的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

时间: 2024-10-18 11:26:48

避免让持续集成服务器成为一个安全隐患!的相关文章

持续集成篇 --Hudson持续集成服务器的安装配置与使用

IP:192.168.4.221  8G内存(Hudson多个工程在同时构建的情况下比较耗内存) 环境:CentOS 6.6.JDK7 Hudson不需要用到数据库   Hudson只是一个持续集成服务器(持续集成工具),要想搭建一套完整的持续集成管理平台,还需要用到前面课程中所讲到的SVN.Maven.Sonar等工具,按需求整合则可. 1.  安装JDK并配置环境变量(略) JAVA_HOME=/usr/local/java/jdk1.7.0_72   2.  Maven本地仓库的安装(使用

pulse 2.4.6发布 持续集成服务器

Pulse是一个持续http://www.aliyun.com/zixun/aggregation/14194.html">集成服务器或构建服务器,其特点是易于使用和具有强大的功能.它能够定期检查SCM中的源代码,来建立项目和通知检查结果.主要功能包括:简单的设置,使用Ajax Web UI进行管理,对现有环境的适应性强,分布式构建,个人构建和个人开发的仪表板和通知参数选择. pulse 2.4.6是2.4版本的第一个稳定版本,增加新功能: *Mercurial SCM support*M

为什么我们迫切需要持续集成?

本文讲的是为什么我们迫切需要持续集成?[编者的话]持续集成(Continuous Integration),也就是我们经常说的 CI,是现代软件开发技术的基础.本文论述了当前软件开发过程中存在的问题,讲解了持续集成.持续集成服务器的概念,最终探讨了为什么我们需要持续集成来解决这些问题. [3 天烧脑式基于Docker的CI/CD实战训练营 | 北京站]本次培训围绕基于Docker的CI/CD实战展开,具体内容包括:持续集成与持续交付(CI/CD)概览:持续集成系统介绍:客户端与服务端的 CI/C

为什么我们迫切需要持续集成(Continuous Integration)

原文同步至 https://waylau.com/why-we-need-continuous-integration/ 持续集成(Continuous Integration),也就是我们经常说的 CI,是现代软件开发技术的基础.本文论述了当前软件开发过程中存在的问题,讲解了持续集成.持续集成服务器的概念,最终探讨了为什么我们需要持续集成来解决这些问题. 当前软件开发过程存在的问题 在没有应用持续集成之前,传统的开发模式是这样的: 项目一开始是先划分好模块,分配模块给相应的开发人员: 开发人员

另一个关于持续集成和版本分支的故事

经典书籍<持续交付>[1]的作者曾就分支合并和代码演化等问题详细地讨论 过滥用分支对持续集成的负面影响.而我今天要说的是这样一个故事,一个只能 申请到非常有限的硬件设备的团队,他们是如何在多分支策略下实践持续集成的 . 一个团队接手了一个项目,需要在开发新特性的同时维护几个发布分支.团队 计划实践持续集成,但手头的硬件资源严重不足,无法满足所有分支的部署流水 线同时运转. 流水线分为三个阶段,分别是: commit 编译.单元测试和部分集成测试并打包 at 部署应用程序并运行自动化验收测试 u

使用 Subversion、Hudson 和 Eclipse 构建持续集成系统

持续集成系统简介 持续集成系统是指持续地编译.测试.检查和部署源代码的系统. Martin Fowler 对 持续集成是这样定义的 : 持续集成是一种软件开发实践,团队开发成员经常集成它们的工作,通常每个成员每天可 能会发生多次集成.每次集成都通过自动化的构建(包括编译.发布.自动化测试)来验证,从而尽快地发现集成错误.这 个过程可以大大减少集成的问题,从而让团队能够更快的开发内聚的软件. 持续集成有以下几个特点和要求: 有统一的源代码库. 开发人员基于同一个源代码库进行开发是进行持续集成的一个

通过持续集成尽早发现缺陷

持续集成(Continuous Integration,CI)是持续地编译.测试.检查和部署 源代码的过程.在许多持续集成环境中,这意味着每当源代码管理库中的代码发 生改变时,都要执行新的构建.CI 的好处很明确:经常组装软件可以大大提高在 早期发现缺陷的可能性,而缺陷在早期还不复杂,容易解决.本教程是 追求代码 质量 系列的配套文章.在本教程中,Andrew Glover 介绍持续集成的基本方面, 并讲解如何用最好的开放源码技术设置 CI 过程. 开始之前 了解本教程讨论的内容以及如何从本教程

超大型系统的持续集成与持续交付解决方案与阿里宙斯盾

作者简介:鲁小川,09年本科毕业于浙江大学软件学院,之后就一直就职于阿里巴巴B2B质量保障部,目前是云效持续集成与持续交付解决方案的负责人. 以下内容根据演讲嘉宾分享以及PPT整理而成. 今天分享的议题是<超大型系统的持续集成与持续交付解决方案及案例分析>,主要就是和大家聊聊阿里巴巴B2B技术部这几年来在持续集成与持续交付上实践经验,以及为什么要做宙斯盾系统平台产品来支撑持续交付.宙斯盾平台在阿里内部经过了5年多的积累沉淀,现在已经对外服务输出了,对外服务产品的名字叫做云效平台,后面还会介绍云

游戏项目中的自动化测试和持续集成

现在,许多游戏项目要么跳票严重,要不就是发布时Bug多多.当然,这样的现象并不仅存于游戏工业.例如,根据2001Standish集团发表的那份 声名狼藉的报告"极度混乱"所表述的,70%以上的软件项目要么被取消,要么严重的超时和超支.然而,游戏是软件开发复杂性的最佳代表,不同技能的人需要 协同工作,这也就是某些人所说的游戏项目中高风险因素所在. 软件项目延期.Bug满天飞和失败的原因是多种多样的,但看起来除了随产品特性不断变化之外,测试和品质管理是永恒的问题.以我们的经验来看,相当多数