安全容器运行时将应用及其依赖环境运行在一个轻量级虚拟机中，为应用Pod提供独立内核层模拟或者细粒度的隔离层，这样可以有效防止容器内部的恶意攻击或漏洞，避免影响到宿主机或其他容器。本文为您介绍安全容器的架构和常用场景。

背景信息

安全容器特别适合于不可信应用隔离、故障隔离、性能隔离、多用户间负载隔离等场景。在提升安全性的同时，对性能影响非常小，并且具备与Docker容器一样的用户体验，例如日志、监控、弹性等。

架构图

核心优势

安全容器是基于社区Kata Containers的轻量虚拟机技术的安全容器运行时，主要核心优势如下：

• 基于轻量虚拟机，实现沙箱之间的超强隔离。
• 具有传统runC容器的应用兼容性。
• 在监控、日志、存储等方面有着runC一致的使用体验。
• 技能门槛要求低、简单易用。
• 兼容开源社区Kata Containers，有关Kata Containers的详细信息，请参见Kata Containers。

CCE 安全容器适用场景

场景一：安全沙箱容器可以强隔离不可信应用

安全容器可以隔离潜在安全风险。

通过把存在潜在安全风险的应用放置到成熟的轻量级虚拟机安全容器中，应用运行在独立的GuestOS Kernel上，即便GuestOS Kernel出现安全漏洞，那么攻击破坏面仅限于一个安全容器内，不会对Host Kernel以及其他容器有任何影响。安全容器容器配合Terway的NetworkPolicy能力，可以灵活地配置Pod的网络访问策略，真正做到系统隔离、数据隔离以及网络隔离。

场景二：解决故障放大、资源争抢、性能干扰方面的问题

Kubernetes使得我们很容易在一个节点上混合部署不同的应用容器，由于Cgroups并不能很好解决资源争抢问题，导致同一节点上相同资源密集型（如CPU密集型、IO密集型等）的不同应用相互争抢资源，导致应用的响应时间出现了严重的波动，总体响应时间偏长。当节点上某一应用异常和故障，如内存泄露、频繁CoreDump等等导致节点整体负载升高，单容器触发Host Kernel Bug导致系统宕机，单应用的故障延展到了整个节点，甚至进一步导致整个集群的不响应。安全容器容器通过独立的GuestOS Kernel和Hypervisor，可以很好地解决Containerd容器在故障放大、资源争抢、性能干扰方面的问题。

场景三：多租户服务

通常一个企业内有多个业务线或部门部署自己的应用，不同的业务线或部门（多个租户）之间有着较强的隔离诉求，如金融类业务不期望自己的物理环境运行着其他非安全敏感应用，传统容器是无法有效避免不可信应用带来的潜在安全风险。有了安全容器后，可以把集群内不可信应用通过虚拟机沙箱隔离起来，而不用担心不可信应用容器逃逸造成的安全风险，这样所有节点都可以混合各类应用容器，这样做的好处是：

• 减少了资源调度的复杂度。
• 节点不再被单个业务独占，减少资源碎片，提高节点资源利用率，节省集群整体资源成本。

使用限制

• 集群版本：仅支持1.28及以上版本的CCE托管集群或CCE独立集群。
• 操作系统：安全容器节点组不支持自定义镜像和GPU镜像，仅支持公共镜像Baidu Linux3。

• 实例规格：仅支持弹性裸金属服务器规格下的这三种套餐：

  • ebc.l5.c128m512.4d
  • ebc.l7.c208m1024.2d
  • ebc.l5.c128m512.1d
• 网络模式：安全容器节点组仅支持VPC-ENI网络模式，不支持独占弹性网卡模式，不支持启用 DataPath v2 功能。