【时速云答疑时间】第五期:如何看待容器的安全性

为促进Docker、Kubernetes等技术的交流传播,同时帮助用户更全面地了解时速云产品及其应用,时速云每周四晚8:30-9:00在用户微信群进行产品、容器技术相关的直播分享和现场答疑。以下整理自9月24日第五期答疑内容,由时速云 联合创始人 杨乐分享。

Docker容器技术发展如火如荼,相关的安全技术也在不断往前推进。我们也在继续探索容器技术应用与安全的问题,这个主题从传统安全角度出发,希望能给大家带来一些思考和讨论。

5答疑1

从传统的角度看,安全不单单是一个技术性的问题,更是一个意识的问题。

在云时代,服务上云已经非常普遍。而安全渗透攻击技术的自动化程度也到了很高水平,受攻击的目标变多,同时攻击者技术手段变高,使我们云端服务的安全环境变的不可预测。

按传统的云端部署方式,比如云台服务器+数据库+web+nginx模式,当出现安全告警时, 我们可以按部就班,升级内核、打补丁、升级服务等,基本上一切从容。

当我们将容器技术应用到部署运维时,打包迁移都是围绕docker, image,这种方式避免了我们在复制运行环境时发生漂移。而在没有处理惯例或者指引的情况下出现安全告警时,这种新的方式带来了新的安全性挑战。

5答疑2

传统攻击目标我们把它看成一个城池或城堡,容器是城池里的房间。传统方式通过信息收集、漏洞发现、渗透入侵等阶段进行系统渗透。

而从容器角度,从房间里边探知里面的信息,这些信息跟城池本身有一定的关联性或者是相似形,从而获取整个系统结构的秘密。

在渗透行为进行的过程中,漏洞对于后续的入侵过程尤为重要。反过来,对企业来说如何及时发现和处理系统漏洞是服务安全的重要部分。

5答疑3

无论是哪种漏洞类型,总会有一个生效周期。产品发布后,渗透人员发现漏洞,到提交漏洞库,或者0day无补丁漏洞。

厂商被通知或自行发现后进行补丁升级,然后是用户升级,更新软件或镜像,最后修补完成。从渗透人员发现漏洞到厂商升级并发布补丁,这段时间属于0day, 危害较大。

对应厂商升级,传统方式和容器有些不同,传统厂商,对相应服务维护升级比较及时,安全性较高。但对容器来说,限于基础镜像安全性,镜像来源也不同,现阶段对镜像的维护升级水平也参差不齐,安全性不可预测。

从全局策略来说,我觉得这一点是容器安全性受质疑的一个重要原因。

5答疑4

大概看一下国外牛人做的一些统计,说Docker Hub上官方的容器镜像有超过30%的数量,包含高风险的安全漏洞,其中有ssh的heartbleed和 bash破壳漏洞。如果对普通用户提交的镜像,这个比例超过40%,抽样误差在3%。

这些数据,是把这些镜像部署上,然后用脚本和公共漏洞数据库 CVE (Common Vulnerabilities and Exposures)对比查找出来的,这些CVE在相应的库里已经评级了,high,Medium,low。

第一组数据看起来还是很可怕的,因为高风险的镜像还是人们经常下载的镜像。然后第二组今年创建的image高危的镜像到40%,高危和中等能到75%,这个也可能是因为今年Docker活跃用户突增,镜像push数量大涨,并且镜像安全质量良莠不齐。最后一组是标有latest的,是image最近更新版,降了不少,这个也是说版本更新会解决一些问题。同时也是给我们提示,镜像最好用latest的,同时经常更新。

5答疑5

这个图是统计了非官方的镜像所用的package的数量对比,从这个图上看到排前三的是bash apt openssl , 这个估计是由于很多镜像用ubuntu基础镜像来的,也就是为什么镜像的漏洞里 bash ssh的占得比例比较大的原因。

列举几个近期的CVE

5答疑6

这几个是docker本身的问题,1.6.1版本的漏洞,基本上属于提权漏洞,只要通过精心设计的镜像就能够exploit。

除了这些CVE,Docker使用过程中也存在一些安全隐患。比如磁盘限额问题,docker本身没有这个功能,如果多租户模式下,某一个应用把磁盘给沾满了,消耗尽了,会严重影响其他容器应用的运行,需要通过辅助手段来解决。再就是超级权限—privileged, 它会赋予容器所有主机的root能力同时挂载所有设备。大家都知道,一般情况下不推荐使用。

我们需要看一下Docker本身的安全机制。Docker 本身使用内核的安全机制,包括Capability,Namespace, Cgroups。而SELinux/appArmor属于访问控制系列。

5答疑7

Capability用于限制容器所拥有的能力,也就是执行某些系统操作的权限,也可以根据需要对容器的能力进行增减。Namespace为每个容器提供隔离的系统运行环境,包括pid, network, uts, ipc, mount。Cgroup主要用于对容器所使用的资源进行限制,包括cpu,memory。技术措施上,对权限和资源进行限制,用cap-drop的方式来削减能力,利用cgroup来为容器添加cpu,和memory限制。这些对Docker比较了解的用户来说,应该耳熟能详了。

通过这些安全机制与参数设置,我们对docker本身能有一个基本的安全操控。Docker社区也在为自身的安全不断的努力。

5答疑8

首先,在开源社区,为代码贡献者指定了代码提交的指导原则,在开发过程中减少bug和漏洞,提高产品质量。同时定期对产品进行渗透测试,及时审计安全漏洞。并开放了相应平台,鼓励安全渗透人员提交漏洞。官方也提供了检测工具,专门为docker的部署运行环境做安全风险初评。

Docker Bench For Security是集成脚本,基本上会从几大方面进行初步检测:

1 – Host Configuration docker检测分区位置,内核版本等是否符合标准
2 – Docker Daemon Configuration 检测Daemon配置,device driver, registry, TLS验证等
3 – Docker Daemon Configuration Files 检测相关文件权限
4 – Container Images and Build Files 容器用户检查,建议非root
5 – Container Runtime 容器SELinux/appArmor配置,资源限制及文件挂载权限等
6 – Docker Security Operations 其他安全选项

对于镜像image,Docker1.8.0版本提供了Docker Content Trust,允许在Docker Hub上下载container images之前检查其合法性。主要是用两个key,进行签名和验证,防止Image被中间篡改。

5答疑9

我认为对于使用者来说,应对容器安全问题,应该具有传统的安全思维同时采用新的技术手段。

除了上文中的具体安全设置,对于容器应用来说,策略上同样是三方面来实施:1.定期渗透测试,安全审计(同docker社区做法));2. 尽量采用image的正规镜像来源,相对于传统安全,容器安全受质疑很大程度上是在于镜像的维护及升级,因此在镜像源头保证安全和及时更新;3.及时升级容器服务,比如采用rollingupdate的方式对跑服务的容器进行升级等方式。

最后,虽然在安全上仍然存在问题,但我们看到,docker在开源社区的关注度、活跃度很高,贡献者也很多,大家群策群力,众人拾柴的情况下,docker容器技术的发展必然会越来越完善。存在的问题也会被逐步克服。

随着这项技术逐渐被大众接受并应用,云端容器应用逐渐会更广泛,再加上渗透安全人员对docker也慢慢熟悉,在未来一段时间内,docker的安全问题会有一个集中突增的时间。但随后docker进步与升级,再加上镜像安全机制的完善,安全问题也会随之慢慢减少。

Q&A精选:

1. 有没有可能做镜像安全性检测?至少基础类镜像。
答:恩,这个后面会提到,安全监测是应该的。

2. Docker Bench For Security是针对docker1.6的安全审计做的工具,不知道有没更新?
答:貌似更新了。当然,这些仅仅是对于docker的运行环境配置参数等进行的安全初评。要想对整个自身的系统服务进行检测,要用专用的渗透工具。

3. private registry 如何接入认证系统?现在只是在nginx上配了认证?
答:我们是docker index,不是nginx认证。可以看看我们在51CTO学院上的视频课程《深入浅出Docker Registry实战》。

4. 有没有很好的认证机制?
答:公开的镜像可以任意pull,除了程序自动验证,解析dockerfile能知道来源。

5. 内核及软件安全的问题是普遍的问题,主动权不在docker手上
答:对,所以docker的态度就是,我把我的代码质量把好关,时常给自己体检。而镜像问题就用策略防御。

 

后记:第五期的话题有点重,在当前以docker为代表的容器技术发展过程中,容器安全还属于探索阶段,时速云以最开放的态度,将自身的见解与努力分享呈现给用户,致力于带来更多的思考与讨论,创造一个良好的发展氛围,推进容器技术的全面发展。有兴趣参与每周四晚8:30-9:00时速云产品、容器技术相关答疑的用户朋友请联系微信xiaoqingshuyeah。欢迎留言告知您想了解的问题或对时速云产品的体验感受,我们会第一时间回复您。

暂无评论

发表评论