安全沙箱概述

背景信息

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

并且相比社区方案（Kata Containers），安全沙箱在存储、网络和稳定性方面都有优化和提升。

架构图

核心优势

ACK安全沙箱和社区Kata Containers对比

场景一：相对于runC容器，安全沙箱（runV）容器可以强隔离不可信应用

• runC容器的安全风险

  

  • 通过Namespace和Cgroups技术隔离的容器攻击面大。

  • 节点上所有容器共享Host Kernel，一旦内核出现漏洞，恶意代码会逃逸到Host上，渗透到后端内网，执行恶意特权代码，破坏系统服务和其他应用，窃取重要数据等。

  • 应用本身的漏洞同样会造成攻击者渗透到内网。

  您可以通过以下措施降低runC容器的安全风险：

  • Seccomp：系统调用过滤。

  • SElinux：限制容器进程、文件和用户的权限。

  • Capability：限制容器进程Capability。

  • Rootless模式：禁止用户以root身份运行容器Runtime和容器。

  虽然以上措施可以在一定程度上强化runC容器的安全性，降低恶意容器应用攻击Host Kernel的几率，但是仍然无法解决容器逃逸利用Host Kernel漏洞的安全问题。

• 安全沙箱（runV）容器隔离潜在安全风险

  

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

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

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

场景三：多租户服务

通常一个企业内有多个业务线或部门部署自己的应用，不同的业务线或部门（多个租户）之间有着较强的隔离诉求，如金融类业务不期望自己的物理环境运行着其他非安全敏感应用，传统runC容器是无法有效避免不可信应用带来的潜在安全风险。这种情况下，通常会选择：

• 多个单租户集群，如金融业务集群和其他非安全敏感业务分隔到多个独立集群。

• 单个多租户集群，需把不同业务线应用分隔到不同的Namespace中，每个节点只可被某个业务线独占，配合资源配额、网络策略等实现多租户隔离。相对于多个单租户集群，管控面较少，管理成本较低，但仍然没有解决因某些租户资源利用率低导致节点资源闲置浪费问题。

  

有了安全沙箱（runV）容器后，可以把集群内不可信应用通过虚拟机沙箱隔离起来，而不用担心不可信应用容器逃逸造成的安全风险，这样所有节点都可以混合各类应用容器，这样做的好处是：

• 减少了资源调度的复杂度。

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

• 安全沙箱（runV）容器使用轻量级虚拟机，性能媲美runC容器。

技术交流&答疑