多云安全之容器安全

  国外AWS、国内阿里云引领云计算的大潮，很多企业都享受着公有云带来云主机弹性售卖模式、BGP网络的低延时、OSS革命性的存储备份方案等。发展一段时间后，我们得知公有云的营收没再次出现爆炸式的增长。究其原因，还是核心业务没有上云。

  大多数企业CTO还是希望自己的核心业务在自己的绝对控制范围内，例如：自建IDC。非核心业务放到公有云上，公有云厂商也逐渐意识到这样的一种情况，如何打破，那为啥不用公有云出的硬件承载你IDC运行的核心系统？于是，AWS推出了Outposts，国内公有云厂商推出了XStack专有云平台，取代原来以VMware为中心的虚拟化平台。伴随着技术的发展，专有云平台也慢慢得到了用户的认可，当时上云还是被公有云SLA所诟病。

  这就是我们现在所处的时代，首先你的用户认可公有云的基础架构便捷，稳定性，其次通过多云管理的方式提升SLA，快速部署业务系统等，本时代的重量级拳手出场：kubernetes。通过它运行在公有云裸金属服务器、云主机上。部署工作负载，kubernetes会通过对接公有云容器运行时接口（CRI）、容器网络接口（CNI）和容器存储接口（CSI），实现核心业务的高可用性。这时候，多云的容器安全解决方案就应运而生。

  容器目前主要有三种运行时形态：1、OS容器+安全机制，2、用户态内核，3、MicroVM，没有一点一种容器运行时技术能满足所有场景的需求，需依据业务需求合理选择，其典型代表，安全隔离方案如图：

  主要原理是在传统 OS 容器之上增加一些辅助安全辅助手段来增加安全性，如SELinux、AppArmor、Seccomp等，还有docker 19.03+可以让Docker运行在 Rootless 的模式之下，其实这些都是通过辅助的工具手段来增强OS容器的安全性，但依然没解决容器与Host共享内核利用内核漏洞逃逸带来的安全风险隐患问题；而且这些安全访问控制工具对管理员认知和技能要求比较高，安全性也相对最差。

  此类典型代表是 Google 的 gVisor，通过实现独立的用户态内核去补获和代理应用的所有系统调用，隔离非安全的系统调用，间接性抵达安全目的，它是一种进程虚拟化增强。但系统调用的代理和过滤的这种机制，导致它的应用兼容性以及系统调用方面性能相对传统OS容器较差。由于并不支持 virt-io 等虚拟框架，扩展性较差，不支持设备热插拔。

  我们知道业界虚拟化(机)本身已经很的成熟，MicroVM轻量虚拟化技术是对传统虚拟化的裁剪和，比较有代表性的就是 Kata-Containers、Firecracker，扩展能力很优秀。VM GuestOS 包括内核均可自由定制，由于具备完整的OS和内核它的应用兼容性及其优秀；独立内核的好处是即便出现安全漏洞问题也会把安全影响区域限制到一个 VM 里面，当然它也有自己的缺点，Overhead 可能会略大一点，启动速度相对较慢一点。

  通过以上对比，我们得知目前OS容器+安全机制这种形态，架构自身的安全性最差，随着容器平台自身架构的完善，会向其他两种形态过度。但是很遗憾的是，目前绝大多数公有云租户还是停留在level 1档位（OS容器+安全机制）。这样就需要一套完整的容器安全平台帮助用户提升平台的安全性。

  作为企业持续集成/连续交付（CI / CD）过程的一部分，集成了镜像扫描过程以防止漏洞，在软件开发生命周期的构建和运行阶段对应用程序进行扫描。强调扫描和识别开源组件，库和框架。研发人员使用较早的，易受攻击的版本是容器漏洞

  在宿主机配置、镜像配置、运行时配置方面，一定要通过使用Internet安全中心（CIS ）基准来加强配置，该基准可用于Docker运行时和Kubernetes。

  在容器运行时阶段，提供白名单，行为监控和异常检测的安全产品，以防止恶意活动。