This documentation is for a release that is no longer maintained
See documentation for the latest supported version 3 or the latest supported version 4.2.10. 已知问题
-
当您使用与这些 pod 关联的项目的卷创建在"SecurityContext"中设置的
RunAsUserName设置的 Windows pod 时,会忽略项目实体的文件所有权权限,从而导致错误配置的所有权权限。 - web 控制台中可用的文件系统图不会显示 Windows 节点。这是因为文件系统查询的改变所致。以后的 WMCO 发行版本中会解决这个问题。(BZ#1930347)
- WMCO 使用的 Prometheus windows_exporter 目前通过 HTTP 来收集指标,因此被视为不安全。您必须确保只有可信用户才能从端点检索指标。windows_exporter 功能最近添加了对 HTTPS 配置的支持,但还没有在 WMCO 中实施此配置。以后的发行版本中将添加对 WMCO 中的 HTTPS 配置的支持。
当在基于 Linux 的 Pod 的安全上下文中设置
RunAsUser权限时,投射文件具有正确的权限集,包括容器用户所有权。但是,如果在 Windows pod 中设置 Windows 等同的RunAsUsername权限,kubelet 将无法为投射卷中的文件设置正确的所有权。如果与一个 hostPath 卷一起使用时,不遵循最佳实践,则此问题可能更加严重。例如,为 pod 授予对C:\var\lib\kubelet\pods\文件夹的访问权限,会导致该 pod 能够从其他 pod 访问服务帐户令牌。默认情况下,投射文件具有以下所有权,如本例 Windows projected 卷文件所示:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 这表示所有管理员用户,如具有
ContainerAdministrator角色的用户,都具有读取、写入和执行访问权限,非管理员用户具有读取和执行访问权限。重要OpenShift Container Platform 将
RunAsUser安全上下文应用于所有 pod,而不考虑其操作系统。这意味着 Windows Pod 会自动将RunAsUser权限应用到其安全上下文。另外,如果使用设置了默认
RunAsUser权限的投射卷创建了 Windows pod,则 pod 会停留在ContainerCreating阶段。为了解决这些问题,OpenShift Container Platform 会在 Pod 安全上下文中设置的服务帐户卷中强制文件权限处理,对于 Windows 上的投射卷,不会满足它们。请注意,Windows pod 的这个行为是 OpenShift Container Platform 4.7 之前用于处理所有 pod 类型的文件权限处理方式。(BZ#1971745)