容器化部署和微服务架构就如同双胞胎，你很难分辨谁先谁后，到底是因为微服务架构逐渐流行促进了容器化部署的成熟，还是由于容器化部署的进步，导致微服务架构逐渐成为主流应用程序架构设计方案。不过笔者从不纠结于这个问题，用一句口头禅来回答就是：这不重要。重要的是开发人员可以将应用程序拆分成粒度合适，可独立部署的微服务。微服务的代码可以被打包到容器镜像中，在Kubernetes这样的容器化编排平台上部署并运行，整个系统的稳定性和灵活性得到了极大的提升。
微服务架构为应用程序设计带了更好的模块化设计，因为服务有清晰的边界，并且每个服务有自己独立的数据库，服务之间通过网络连接。这种粒度适中的，可独立部署和运维的架构方式，除了带给我们设计和部署的灵活性，也提升了测试的便利性，甚至是安全性。
笔者在系列文章中一直在强调攻击界面的问题，就如同我们要保障一间有5扇门的房间和一间只有1扇门的房间，很明显1扇门的房间更加容易。回到微服务架构，由于每个服务都只提供特定的服务，因此代码量会更少，并且代码依赖的外部库也相应的减少，因此整个应用（服务）的攻击面相应的缩减，作为开发和运维人员，我们就很容易构建应用准确的runtime profile，来准确的约束应用在运行的时候，运行执行的系统调用，访问的系统资源等。
从最佳实践的角度来讲，我们应该让容器实例具备不可变性，相同容器镜像创建出来的容器实例应该完全等同（无论是配置还是行为），因此在容器镜像中定义容器运行安全策略就显得很合理。咱们通过一个具体的例子来说明一下，笔者在华南某头部客户电商项目上，商品中心提供了商品搜索服务，服务接受前端的查询请求，查询请求中包含了具体的搜索条件，比如基于产品名称，关键字等。商品搜索服务会对请求参数进行反序列化，然后从前端传入的请求中extract出查询条件，构建ES查询条件，将请求发给ES来执行具体的商品检索任务。
咱们来分析一下这个场景，对于商品搜索服务来讲，因为要接受客户端的Web查询请求，因此容器实例必须能够被ingress或者负载均衡器访问，并且具体的查询执行在ES，因此商品搜索服务也应该能够访问访问ES实例。从网络连接的角度，除了提供Ingress和负载均衡器的外部访问和连接ES之外，商品搜索服务不应该有这两种之外的任何网络流量（当然必须包含日志agent以及health checks流量）。
有了上边对搜索服务的分析结果，我们很容易为搜索服务定义网络策略来提供商品检索功能的同时，加固了容器实例的安全边界。除了运维人员自己编写安全profile配置之外，业界已经出现了很多成熟的工具，这些工具可以运行在recording模式下，来收集一段时间应用程序运行需要的系统调用，访问的资源类型，然后基于这些信息自动为容器创建防火墙规则或者网络策略，来减轻运维压力。
除了网络策略之外，我们还可以通过技术手段来约束容器实例中可运行的可执行文件。咱们继续前边商品搜索的例子，由于这个ProductSearch的服务只提供商品搜索，并且服务基于Java开发，因此如果我们监控运行在容器实例中的进程，我们应该只应该看到productsearch这个进程，当容器实例中启动了其他任何进程的时候，我们的监控系统应该发出警告，通知运行人员系统可能受到攻击，需要人工介入。
那么我们如何能“知道”容器实例运行了哪些可执行文件呢？业界有很多工具可以选择，笔者不打算逐一介绍，决定只介绍这些工具底层使用的Linux内核工具eBPF。接下来咱们通过运行nginx容器实例来介绍eBPF这个工具，当我们启动一个nginx容器实例，如果我们通过Tracee这个工具来监控容器实例中运行进程，我们只会看到nginx进程。Tracee工具底层使用的就是eBPF，也叫扩展伯克利数据包过滤器（Extended Berkeley Packet Filter）。
eBPF允许运行其上的工具给操作系统内核插入代码，内核会在数据包的处理过程中，调用这些代码，因此使用eBPF需要持有root权限。接下来咱们通过一个具体的例子来说明一下，咱们先在一个控制台启动Tracee工具，然后在另外一个窗口通过命令：docker run --rm -d --name nginx nginx 启动运行ngxin容器实例，当nginx启动后，我们就可以在Tracee窗口看到如下的输出：
EVENT ARGS
execve /usr/sbin/nginx
接着咱们通过docker exec在nginx容器实例中运行另外一个命令ls，docker exec -it nginx ls，回到Tracee窗口就能看到工具准确的捕捉到了可执行文件信息，如下输出所示：
EVENT ARGS
execve /usr/sbin/nginx
execve /bin/ls
有了这个工具监控我们的容器实例中运行的可执行文件后，咱们来分析一下如果应用受到恶意攻击者的攻击，黑客给容器实例中注入了比特币挖矿代码，当挖矿客户端启动的时候，Tracee能够马上就监控到这个可执行文件，进而通知运维人员来处理。
eBPF除了能够监控运行在容器中可执行文件之外，还可以监控访问文件系统，用户标识以及系统调用等。通过eBPF，我们可以监控所有和访问文件系统相关的系统调用，基于这些信息我们就可以为运行在容器中的应用程序配置必要的文件系统访问清单，如果发现容器访问白名单之外的文件系统路劲，就可以告警来提醒运维人员潜在的安全风险。
在笔者的机器上通过Tracee工具就可以观测到nginx容器实例需要访问的文件清单：
openat /etc/ld.so.cache
openat /lib/x86_64-linux-gnu/libdl.so.2
openat /lib/x86_64-linux-gnu/libpthread.so.0
openat /lib/x86_64-linux-gnu/libcrypt.so.1
openat /lib/x86_64-linux-gnu/libpcre.so.3
openat /usr/lib/x86_64-linux-gnu/libssl.so.1.1
openat /usr/lib/x86_64-linux-gnu/libcrypto.so.1.1
openat /lib/x86_64-linux-gnu/libz.so.1
openat /lib/x86_64-linux-gnu/libc.so.6
openat /etc/localtime
openat /var/log/nginx/error.log
openat /usr/lib/ssl/openssl.cnf
openat /sys/devices/system/cpu/online
openat /etc/nginx/nginx.conf
（为了节省空间，省略若干）
Tracee除了可以监控文件系统访问路径清单之外，还可以监控容器实例的UID，特别是我们使用非root账号运行我们的应用程序，如果Tracee工具检测到容器实例使用另外的用户账号，那么就应该马上进行告警，特别是监控到容器中有root账号在运行，那么就应该马上进行处理，避免造成更大的损失。
最后，Tracee还可以监控到进程使用的系统调用，比如如下的capabilities清单就是我们运行nginx容器实例的时候从Tracee工具控制台看到的：
CAP_CHOWN
CAP_DAC_OVERRIDE
CAP_DAC_READ_SEARCH
CAP_NET_BIND_SERVICE
CAP_SETGID
CAP_SETUID
CAP_SYS_ADMIN
特别对微服务架构下的服务来说，由于每个服务承担的职责和提供的服务能力缩小，因此从实操层面比起单体应用，微服务架构下的应用通过约束系统调用，监控可执行程序，控制capabilities变成可行。
好了, 这篇文章的内容就这么多了，这也是我们的容器安全系列文章的最后一篇。有了容器安全系列文章打底，咱们接下来会体系化的介绍Kubernets的安全体系，敬请期待！
