你的容器安全吗

容器的供给面

前言

说到容器的安全，就不得不提下CIS （Center for Internet Security)基线。他提供的指导手册包含详细的检测和评估方法，被广泛接受位保障容器和虚拟机安全的最佳实践。

但只有近距离看底层的设计细节，才能知道为什么要这么操作。

容器的全局

视角拉远，让我们看看容器从开发，构建再到部署环境的各种要素：

不信任的应用和库

无论是宿主机操作系统（OS)， 容器运行时（Container Runtime),甚至是开发工具（IDE）。 我们开发的应用还是应用依赖的平台和库，都是由工程师写的。
这些自身就存在一些漏洞，例如Docker Issue 37583等。
有些漏洞甚至可以让低权限用户实现本地提权。

不规范的容器镜像配置

当代码开发完毕后，开始进行容器镜像构建时，也可能引入新的安全漏洞。
以Dockerfile为例:

• 当未指定启动的账户时，Docker runtime会使用Root身份启动容器。
• 密钥被以明文的方式，封存在容器镜像中。后续就可能通过docker save xxx>xxx.tar的形式获取密码。

不安全的rootfs

应用正常运行的库和工具集，也会出现漏洞，最后成为容器逃逸的帮凶。

容器里安装应用

部分容器方案，会在启动的时候通过动态更新应用的方式达到升级版本的目的，例如NPM, APT & DOTNET。
这往往也带来了安全漏洞。

不安全的镜像源 & 版本

对于使用公共镜像源的场景下，一旦网络被劫持，或者镜像被串改，就会导致部署时拉取到错误的镜像。
特别是拉取时未指定版本，默认采用latest。就会导致不稳定和不安全的镜像被应用到生产环境中，引入安全漏洞。

不安全的网络

容器网络和宿主机网络是两个独立的网络方案，但是容器网络又是可以被宿主机网络开放的。Kubernetes要求Pod之间可以互相访问。但不加约束，就会导致一个Pod沦陷，就会扩散到整个K8S网络。

容器逃逸

容器逃逸，指攻击者通过漏洞，劫持容器中的应用，进而一步步获取容器，宿主机的命令执行权限。

以CVE-2019-5736为例。

不安全的编译环境

从代码到镜像构建，会经历各种构建流程，中间也可能被引入各种安全漏洞。