第 1 章 了解 OpenShift 沙盒容器


OpenShift 沙盒容器支持 Red Hat OpenShift Container Platform 为您提供了将 Kata Containers 作为额外可选运行时运行的内置支持。新的运行时支持专用虚拟机 (VM) 中的容器,从而改进了工作负载隔离。这对执行以下任务特别有用:

运行特权或不受信任的工作负载

OpenShift 沙盒容器 (OSC) 使得可以安全地运行需要特定特权的工作负载,而无需通过运行特权容器来破坏集群节点的风险。需要特殊权限的工作负载包括:

  • 需要内核的特殊功能的工作负载,除了标准容器运行时(如 CRI-O)授予的默认功能外,例如访问低级别网络功能。
  • 需要提高 root 特权的工作负载,例如访问特定物理设备。使用 OpenShift 沙盒容器时,只能将特定的设备传递给虚拟机,确保工作负载无法访问或错误配置系统的其余部分。
  • 用于安装或使用 set-uid root 二进制文件的工作负载。这些二进制文件授予特殊权限,因此可能会造成安全风险。使用 OpenShift 沙盒容器时,对虚拟机有额外的权限,不授予对集群节点的特殊访问权限。

有些工作负载可能需要专门用于配置集群节点的权限。此类工作负载应该仍然使用特权容器,因为在虚拟机上运行可能会阻止它们正常工作。

确保每个工作负载的内核隔离
OpenShift 沙盒容器支持需要自定义内核调整(如 sysctl、调度程序更改或缓存调整)以及创建自定义内核模块(如 out of tree 或特殊参数)的工作负载。
在租户间共享相同的工作负载
OpenShift 沙盒容器允许您支持来自共享同一 OpenShift 集群的不同组织的多个用户(租户)。该系统还允许您从多个供应商运行第三方工作负载,如容器网络功能 (CNF) 和企业应用程序。例如,第三方 CNF 可能不希望其自定义设置与数据包调整或由其他应用程序设置的 sysctl 变量干扰。在完全隔离的内核内运行有助于防止"邻居噪音"配置问题。
确保正确隔离和沙盒测试软件
您可以使用 OpenShift 沙盒容器来运行具有已知漏洞的容器化工作负载,或者处理传统应用程序中的问题。通过这种隔离,管理员可以为开发人员提供对 pod 的管理控制,这在开发人员想要测试或验证管理员通常授权的配置时很有用。例如,管理员可以安全地将内核数据包过滤 (eBPF) 委派给开发人员。内核数据包过滤需要 CAP_ADMINCAP_BPF 权限,因此不允许在标准 CRI-O 配置下,因为这会授予容器主机 worker 节点上的每个进程的访问权限。类似地,管理员可以授予对 SystemTap 等入侵工具的访问权限,或者支持在开发期间加载自定义内核模块。
确保通过虚拟机边界的默认资源控制
默认情况下,CPU、内存、存储或网络等资源以 OpenShift 沙盒容器中的更加强大和安全的方式进行管理。由于 OpenShift 沙盒容器部署到虚拟机上,因此额外的隔离层和安全性可为资源提供更精细的访问控制。例如,错误容器将无法分配超过虚拟机可用内存更多的内存。相反,需要专用访问网卡或磁盘的容器可以完全控制该设备,而无需访问其他设备。

1.1. OpenShift 沙盒容器支持的平台

您可以在裸机服务器或 Amazon Web Services (AWS) 裸机实例上安装 OpenShift 沙盒容器。不支持由其他云提供商提供的裸机实例。

Red Hat Enterprise Linux CoreOS (RHCOS) 是 OpenShift 沙盒容器唯一支持的操作系统。

OpenShift 沙盒容器 1.5 与所有支持的 Red Hat OpenShift Container Platform 版本兼容。详情请参阅 OpenShift Operator 生命周期

返回顶部
Red Hat logoGithubredditYoutubeTwitter

学习

尝试、购买和销售

社区

关于红帽文档

通过我们的产品和服务,以及可以信赖的内容,帮助红帽用户创新并实现他们的目标。 了解我们当前的更新.

让开源更具包容性

红帽致力于替换我们的代码、文档和 Web 属性中存在问题的语言。欲了解更多详情,请参阅红帽博客.

關於紅帽

我们提供强化的解决方案,使企业能够更轻松地跨平台和环境(从核心数据中心到网络边缘)工作。

Theme

© 2025 Red Hat