第 1 章 关于 OpenShift 沙盒容器
用于 OpenShift Container Platform 的 OpenShift 沙盒容器将 Kata 容器集成为可选运行时，通过在轻量级虚拟机中运行容器化应用程序来提供增强的安全性和隔离功能。此集成为敏感工作负载提供了一个更安全的运行时环境，而无需对现有 OpenShift 工作流进行大量更改。此运行时支持专用虚拟机(VM)中的容器，从而改进了工作负载隔离。
1.1. 功能
OpenShift 沙盒容器提供以下功能：
- 运行特权或不受信任的工作负载
您可以安全地运行需要特定特权的工作负载，而无需通过运行特权容器来破坏集群节点的风险。需要特殊权限的工作负载包括：
- 需要内核的特殊功能的工作负载，除了标准容器运行时（如 CRI-O）授予的默认功能外，例如访问低级别网络功能。
- 需要提高 root 特权的工作负载，例如访问特定物理设备。使用 OpenShift 沙盒容器时，只能将特定的设备传递给虚拟机(VM)，确保工作负载无法访问或错误配置系统的其余部分。
用于安装或使用
set-uidroot 二进制文件的工作负载。这些二进制文件授予特殊权限，因此可能会造成安全风险。使用 OpenShift 沙盒容器时，对虚拟机有额外的权限，不授予对集群节点的特殊访问权限。有些工作负载需要专门用于配置集群节点的权限。此类工作负载应该仍然使用特权容器，因为在虚拟机上运行可能会阻止它们正常工作。
- 确保敏感工作负载的隔离
- Red Hat OpenShift Container Platform 的 OpenShift 沙盒容器将 Kata 容器集成为可选运行时，通过在轻量级虚拟机中运行容器化应用程序来提供增强的安全性和隔离功能。此集成为敏感工作负载提供了一个更安全的运行时环境，而无需对现有 OpenShift 工作流进行大量更改。此运行时支持专用虚拟机(VM)中的容器，从而改进了工作负载隔离。
- 确保每个工作负载的内核隔离
-
您可以运行需要自定义内核调整（如
sysctl、调度程序更改或缓存调整）以及创建自定义内核模块（如树外或特殊参数）的工作负载。 - 在租户间共享相同的工作负载
-
您可以从共享同一 OpenShift Container Platform 集群的不同机构运行支持许多用户（租户）的工作负载。系统还支持从多个供应商运行第三方工作负载，如容器网络功能(CNF)和企业应用程序。例如，第三方 CNF 可能不希望其自定义设置与数据包调整或由其他应用程序设置的
sysctl变量干扰。在完全隔离的内核内运行有助于防止"邻居噪音"配置问题。 - 确保正确隔离和沙盒测试软件
-
您可以使用已知漏洞运行容器化工作负载，或处理现有应用程序中的问题。通过这种隔离，管理员可以为开发人员提供对 pod 的管理控制，这在开发人员想要测试或验证管理员通常授予的配置时很有用。例如，管理员可以安全地将内核数据包过滤(eBPF)委派给开发人员。eBPF 需要
CAP_ADMIN或CAP_BPF特权，因此不允许在标准 CRI-O 配置下，因为这会授予容器主机 worker 节点上的每个进程的访问权限。同样，管理员可以授予对SystemTap等入侵工具的访问权限，或者支持在开发期间加载自定义内核模块。 - 确保通过虚拟机边界的默认资源控制
- 默认情况下，OpenShift 沙盒容器以强大和安全的方式管理 CPU、内存、存储和网络等资源。由于 OpenShift 沙盒容器部署到虚拟机上，因此额外的隔离层和安全性可为资源提供更精细的访问控制。例如，错误容器将无法为虚拟机分配超过可用内存更多的内存。相反，需要专用访问网卡或磁盘的容器可以完全控制该设备，而无需访问其他设备。
