IBM Cloud Docs
Red Hat OpenShift on IBM Cloud 的安全性

Red Hat OpenShift on IBM Cloud 的安全性

您可以使用 Red Hat® OpenShift® on IBM Cloud® 中的内置安全功能来进行风险分析和安全保护。 这些功能有助于保护集群基础架构和网络通信，隔离计算资源，以及确保基础架构组件和容器部署中的安全合规性。

集群安全威胁概述

要保护集群不被破坏，您必须了解集群的潜在安全威胁以及可以采取哪些措施来减少暴露于漏洞的风险。

外部攻击
攻击者可获取对集群以及已部署资源、应用程序或个人信息的访问权。
有漏洞的部署
已知漏洞会被利用来访问云环境并运行恶意软件。
数据遭到破坏或丢失
敏感数据存储不正确，加密功能缺失。
内部人员和第三方供应商
网络隔离和分段的缺失会导致合法权限被滥用。

近几年来，随着公司不断将工作负载移至公共云中，云安全性以及防御对系统、基础架构和数据的攻击变得非常重要。 集群由多个组件组成，每个组件都可能使环境面临遭受恶意攻击的风险。 要保护群集免受这些安全威胁，必须确保在所有群集组件中应用最新的 Red Hat OpenShift on IBM Cloud、Red Hat OpenShift 和 Kubernetes 安全功能和更新。

这些组件包括：

Red Hat OpenShift API 服务器和 etcd

Red Hat OpenShift API 服务器和 etcd 数据存储是在 Red Hat OpenShift 主站中运行的最敏感组件。 您希望防止对这些组件进行未经授权的访问，因为这些组件设置并存储集群中运行的所有资源的配置，包括应用程序的某些安全设置。

Red Hat OpenShift 提供安全控制并限制访问，以保护这些组件并降低网络攻击的风险。

如何授权访问我的 API 服务器？

默认情况下，Kubernetes 在允许访问 API 服务器之前，每个请求都需要经过几个阶段。

认证
验证注册用户或服务账户的身份。
授权
限制已通过身份验证的用户和服务账户的权限，确保他们只能访问和操作所需的群集组件。
许可控制
在 Red Hat OpenShift API 服务器处理请求之前对其进行验证或变异。 Kubernetes 的许多功能都需要接入控制器才能正常运行。

Red Hat OpenShift on IBM Cloud 如何确保 API 服务器和 etcd 数据存储的安全？

下图显示了用于处理认证、授权、许可控制以及 Kubernetes 主节点与工作程序节点之间安全连接的缺省集群安全设置。

描述访问API服务器时的安全阶段。
访问API服务器时的安全阶段

查看 Red Hat OpenShift API 服务器和 etcd的以下安全功能。

全面管理和专用的 Red Hat OpenShift 主站

Red Hat OpenShift on IBM Cloud 中的每个群集都由一个专用的 Red Hat OpenShift 主控器控制，该主控器由 IBM 在 IBM-owned IBM Cloud 账户中管理。 Red Hat OpenShift 主站设置了以下专用组件，不与其他 IBM 客户共享。

  • etcd 数据存储： 存储集群的所有 资源，如、和。Kubernetes Services Deployments Pods Kubernetes ConfigMaps 和 Secrets 是存储为键/值对的应用程序数据，可由 pod 中运行的应用程序使用。 etcd 中的数据存储在 Red Hat OpenShift 主控器的本地磁盘上，并备份到 IBM Cloud Object Storage。 数据在传输到 IBM Cloud Object Storage 期间和处于静态时会进行加密。 您可以选择通过为群集 启用 IBM Key Protect 加密，为 Red Hat OpenShift 主控本地磁盘上的 etcd 数据加密。 将 etcd 数据发送到 pod 时，这些数据会通过 TLS 加密以确保数据保护和完整性。
  • openshift-api： 作为从工作节点到 Red Hat OpenShift 主节点的所有集群管理请求的主要入口点。 该 API 服务器会验证并处理会更改集群资源（例如，pod 或服务）的状态的请求，并将此状态存储在 etcd 数据存储中。
  • openshift-controller： 监控新创建的 pod，并根据容量、性能需求、策略限制、反亲和规范和工作负载要求决定将它们部署到哪里。 如果找不到与这些需求相匹配的工作程序节点，那么不会在集群中部署 pod。 控制器还会监视集群资源（例如，副本集）的状态。 当资源的状态更改时（例如，如果副本集内的 pod 停止运行），控制器管理器会开始更正操作以实现所需的状态。
  • 云控制器管理器： 云控制器管理器管理特定于云提供商的组件，如 IBM Cloud 负载平衡器。
  • Konnectivity: Red Hat OpenShift on IBM Cloud 专用组件，为所有 Red Hat OpenShift 主节点到工作节点的通信提供安全的网络连接。 Konnectivity 服务器与 Konnectivity 代理合作，将主节点与工作节点安全地连接起来。 此连接支持向 pod 和服务发送 apiserver proxy 请求，以及向 kubelet 发送 oc exec、attach 和 logs 请求。 从工作程序节点到主节点的连接通过 TLS 证书自动进行保护。
由 IBM 现场可靠性工程师 (SRE) 持续监视

Red Hat OpenShift 主站（包括所有主站组件、计算、网络和存储资源）由 IBM 网站可靠性工程师（SRE）持续监控。 SRE 将应用最新的安全标准，检测恶意活动并进行修复，以及设法确保 Red Hat OpenShift on IBM Cloud 的可性和可用性。

CIS Kubernetes 主节点基准

要配置 Red Hat OpenShift on IBM Cloud，IBM 工程师要遵循 互联网安全中心(CIS ) 发布的 Kubernetes 主基准中的相关网络安全实践。 集群主节点和所有工作程序节点都使用满足基准的映像进行部署。

通过 TLS 保护通信

要使用 Red Hat OpenShift on IBM Cloud，您必须使用自己的凭证向服务进行认证。 通过身份验证后，Red Hat OpenShift on IBM Cloud 会生成 TLS 证书，对与 Red Hat OpenShift API 服务器和 etcd 数据存储之间的通信进行加密，以确保工作节点和 Red Hat OpenShift 主节点之间的端到端通信安全。 这些证书绝不会在集群或 Red Hat OpenShift 主控组件之间共享。

与工作程序节点的连接

虽然 Kubernetes 通过使用 https 协议确保主节点和工作节点之间的通信安全，但默认情况下工作节点不提供身份验证。 为确保通信安全，Red Hat OpenShift on IBM Cloud 会在创建群集时自动在 Red Hat OpenShift 主节点和工作节点之间建立 Konnectivity 连接。

细颗粒度访问控制

作为帐户管理员，您可以 使用 IBM Cloud Identity and Access Management(IAM)授予其他用户对 Red Hat OpenShift on IBM Cloud 的访问权。IBM Cloud IAM 向 IBM Cloud 平台，Red Hat OpenShift on IBM Cloud和帐户中的所有资源提供安全认证。 设置适当的用户角色和权限是限制谁能访问资源以及限制用户在滥用合法权限时可能造成的损害的关键。 可以从以下预定义的用户角色中进行选择，以确定用户可以执行的操作集：

  • 平台访问角色： 确定用户可以在 Red Hat OpenShift on IBM Cloud 中执行的群集和工作节点管理相关操作。 平台访问角色还会为用户分配 basic-users 和 self-provisioners RBAC 角色。 有了这些 RBAC 角色，就可以在群集中创建 Red Hat OpenShift 项目，在其中部署应用程序和其他 Kubernetes 资源。 作为项目的创建者，您会自动分配有对该项目的 admin RBAC 角色，因此您可以完全控制要在项目中部署和运行的对象。 不过，这些 RBAC 角色不授予访问其他 Red Hat OpenShift 项目的权限。 要查看和访问其他 Red Hat OpenShift 项目，您必须在 IAM 中分配相应的服务访问角色。
  • 服务访问角色： 确定分配给用户的 Kubernetes RBAC 角色，以及用户可对 Red Hat OpenShift API 服务器执行的操作。 虽然与平台访问角色一起分配的 basic-users 和 self-provisioners RBAC 角色可让您创建和管理自己的 Red Hat OpenShift 项目，但在分配服务访问角色之前，您无法查看、访问或处理其他 Red Hat OpenShift 项目。 有关分配给用户的相应 RBAC 角色和相关权限的更多信息，请参阅 IAM 服务访问 角色。
  • 经典基础设施： 允许访问传统基础架构资源。 经典基础架构角色允许的示例操作包括查看集群工作程序节点机器的详细信息或编辑联网和存储资源。
  • VPC 基础设施： 允许访问 VPC 基础设施资源。 VPC 基础架构角色允许的示例操作包括创建 VPC，添加子网，更改浮动 IP 地址以及创建 VPC Block Storage 实例。

有关群集中访问控制的更多信息，请参阅 分配群集访问权限。

许可控制器

在 Kubernetes 和 Red Hat OpenShift on IBM Cloud 中，实施了用于特定功能的许可控制器。 通过许可控制器，可以在集群中设置策略，用于确定是否允许执行集群中的特定操作。 在策略中，您可以指定用户不能执行操作的条件，即使该操作是您使用 RBAC 角色分配给用户的一般权限的一部分。 因此，在 Red Hat OpenShift API 服务器处理 API 请求之前，准入控制器可为集群提供额外的安全保护。

创建集群时，Red Hat OpenShift on IBM Cloud 将以特定顺序在 Red Hat OpenShift 主节点中自动安装缺省 Kubernetes 许可控制器，用户无法更改该控制器。 在 kube-apiserver 组件参考信息 中按集群版本查看缺省许可控制器的顺序。

您可以 在集群中安装自己的许可控制器 或选择可选许可控制器，例如 Portieris。 通过 Portieris，可以阻止来自未签名映像的容器部署。

如果您手动安装了入场控制器，但不想再使用它们，请确保将其完全删除。 如果许可控制器未完全除去，可能会阻止您要在集群上执行的所有操作。

我还能做些什么来保护我的 API 服务器？

您可以通过以下几种方式限制与群集主控程序的网络连接

  • 仅启用私有云服务端点：只有经典 OpenShift 集群才需要公共服务端点。 所有 VPC 群集都可以禁用该功能。 只要您的账户已 启用 VRF 和服务端点，也可以禁用传统 Kubernetes 群集。 这可以保护群集主控免受公共网络攻击。
  • 启用基于上下文的限制：您可以使用基于上下文的限制 (CBR) 确保对群集的专用和公共服务终端的网络访问安全。 只允许向群集主控发送来自 CBR 规则中子网的授权请求。 更多信息，请参阅 使用基于上下文的限制。

工作程序节点

工作程序节点具有组成应用程序的部署和服务。 在公共云中托管工作负载时，您希望确保应用程序受到保护，不会被未经授权的用户或软件访问、更改或监视。

谁拥有工人节点，我是否有责任保护它？

工作程序节点的所有权取决于创建的集群类型以及选择的基础架构提供者。

  • 经典集群：工作节点配置到 IBM Cloud 账户。 工作程序节点专供您使用，您将负责请求及时更新工作程序节点，以确保工作程序节点操作系统和 IBM Cloud Kubernetes Service 组件应用最新的安全性更新和补丁。
  • VPC 集群：工作节点被配置到 IBM 所拥有的 IBM Cloud 账户中，以便监控恶意活动并应用安全更新。 使用 VPC 面板无法访问工作节点。 但是，可以使用 IBM Cloud Kubernetes Service 控制台、CLI 或 API 来管理工作程序节点。 构成工作程序节点的虚拟机专供您使用，您将负责请求及时更新，以便工作程序节点操作系统和 IBM Cloud Kubernetes Service 组件应用最新的安全性更新和补丁。

有关更多信息，请参阅使用 Red Hat OpenShift on IBM Cloud 的责任。

定期（如每月）使用 ibmcloud oc worker update 命令 为操作系统部署更新和安全补丁，并更新工作节点运行的 Red Hat OpenShift 版本。 更新可用时，您在 IBM Cloud 控制台或 CLI（如使用 ibmcloud oc clusters ls 或 ibmcloud oc workers ls --cluster <cluster_name> 命令）中查看有关主节点和工作节点的信息时会收到通知。 工作程序节点更新由 IBM 以包含最新安全补丁的完整工作程序节点映像形式提供。 要应用更新，必须使用新映像重新创建工作程序节点的映像并重新装入工作程序节点。 重新装入工作程序节点时，会自动轮换 root 用户的密钥。

我的工作节点设置如何？

下图显示了为每个工作程序节点设置的组件，用于保护工作程序节点免受恶意攻击。

此图不包含用于确保与工作程序节点之间安全端到端通信的组件。 有关更多信息，请参阅网络安全性。

Red Hat OpenShift on IBM Cloud 中的工作程序节点设置 (不包括网络安全)。
工作节点设置 Red Hat OpenShift on IBM Cloud 不包括网络安全

CIS-顺从的形象
每个工作节点都安装了一个操作系统，该操作系统执行由互联网安全中心 ( CIS ) 发布的基准。 用户或机器所有者无法将此操作系统更改为其他操作系统。 要查看当前的操作系统版本，请运行 oc get nodes -o wide。 IBM 与内部和外部安全咨询团队合作，应对潜在的安全合规性漏洞。 操作系统的安全性更新和补丁通过 Red Hat OpenShift on IBM Cloud 提供，用户必须安装这些更新和补丁，才能使工作程序节点保持安全。

Red Hat OpenShift on IBM Cloud 工作节点使用 内核。Linux 您可以基于 Red Hat OpenShift on IBM Cloud 中的任何 Linux 分发版来运行容器。 请与容器映像供应商联系，确认容器映像可以在内核上运行。

由现场可靠性工程师 (SRE) 持续监视
工作程序节点上安装的映像由 IBM 现场可靠性工程师 (SRE) 持续监视，以检测漏洞和安全合规性问题。 为了解决漏洞，SRE 会为工作程序节点创建安全补丁和修订包。 请确保在这些补丁可用时应用它们，以确保为您的工作节点和在其上运行的应用程序提供一个安全的环境。
CIS Kubernetes 工作程序节点基准
在配置 Red Hat OpenShift on IBM Cloud 时，IBM 工程师会遵循 互联网安全中心(CIS ) 发布的 Kubernetes 工作节点基准中的相关网络安全实践。 您可以查看工作程序节点是否符合 CIS Kubernetes benchmark 和 Red Hat OpenShift benchmark 标准。
计算隔离
工作节点专用于一个群集，不承载其他群集的工作负载。 创建经典群集时，您可以选择将工作节点配置为物理机（裸机）或在共享或专用物理硬件上运行的虚拟机。 VPC 集群中的工作程序节点只能作为共享基础结构上的虚拟机供应。
用于在经典上部署裸机的选项
如果创建标准经典集群，那么可以选择在裸机物理服务器（而不是虚拟服务器实例）上供应工作程序节点。 使用裸机机器时，您将对计算主机（例如，内存或 CPU）具有更多控制权。 此设置无需虚拟机系统管理程序将物理资源分配给在主机上运行的虚拟机。 相反，裸机的所有资源都专门用于工作者，所以你不必担心“吵闹的邻居”会共享资源或降低性能。 裸机服务器专供您使用，其所有资源可供集群使用。
加密磁盘
缺省情况下，会为每个工作程序节点供应两个本地 SSD AES 256 位加密数据分区。 第一个分区包含用于引导工作程序节点并且未进行加密的内核映像。 第二个分区保存容器文件系统并可使用 LUKS 加密密钥对其解锁。 集群中的每个工作程序节点都有自己的唯一 LUKS 加密密钥，由 Red Hat OpenShift on IBM Cloud 管理。 当您创建集群或将工作程序节点添加到现有集群时，将安全地拉取密钥，然后在解锁加密磁盘后废弃。 加密可能会影响磁盘 I/O 性能。 对于需要高性能磁盘 I/O 的工作负载，在启用和禁用加密的情况下测试集群以帮助您确定是否关闭加密。
SELinux
每个工作节点都设置了安全和访问策略，这些策略由 安全增强型 Linux(SELinux) 配置文件执行，这些配置文件在启动过程中加载到工作节点中。 SELinux 配置文件不能由用户或机器所有者更改。
SSH 已禁用
缺省情况下，工作程序节点上禁用了 SSH 访问，以保护集群免受恶意攻击。 禁用 SSH 访问时，将强制通过 Red Hat OpenShift API 服务器访问群集。 Red Hat OpenShift API 服务器要求在集群中执行请求之前，根据身份验证、授权和准入控制模块中设置的策略检查每个请求。
如果您有一个标准集群，但想在工作节点上安装更多功能，您可以选择 Red Hat OpenShift on IBM Cloud 提供的附加组件，或使用 Kubernetes 守护进程集来安装您想在每个工作节点上运行的所有功能。 对于必须执行的任何一次性操作，请使用 Kubernetes 作业。

网络

保护公司网络的典型方法是设置防火墙，并阻止任何不需要的网络流量流至应用程序。 虽然这种做法仍然很有用，但研究表明，许多恶意攻击来自内部人员或滥用所分配许可权的授权用户。

经典集群的网络分段和隐私

要保护网络并限制在授予网络访问权后用户可能造成的损害范围，您必须确保尽可能隔离工作负载，并且限制公共公开的应用程序和工作程序节点的数量。

我的 Classic 集群默认允许哪些网络流量？

所有容器都通过集群创建期间在每个工作程序节点上配置的预定义 Calico 网络策略设置进行保护。 缺省情况下，所有工作程序节点都允许所有出站网络流量。 入站网络流量会被阻止，但有以下例外：

从 Red Hat OpenShift 主节点到工作节点 kubelet 的访问由 Konnectivity 隧道保护。 有关更多信息，请参阅 Red Hat OpenShift on IBM Cloud 体系结构。

什么是网络分段，如何为 Classic 集群设置网络分段？

网络分段描述了用于将网络划分为多个子网的方法。 您可以对要由组织中特定组访问的应用程序和相关数据分组。 在一个子网络中运行的应用程序无法看到或访问另一个子网络中的应用程序。 网络分段还会限制提供给内部人员或第三方软件的访问权，并且可以限制恶意活动的范围。

Red Hat OpenShift on IBM Cloud 提供了 IBM Cloud VLAN，用于确保工作程序节点的高质量网络性能和网络隔离。 VLAN 会将一组工作程序节点和 pod 视为连接到同一物理连线那样进行配置。 VLAN 专用于您的 IBM Cloud 帐户，而不是在 IBM 客户之间共享。 在经典集群中，如果有多个 VLAN 用于集群，有多个子网位于同一 VLAN 上，或有一个多专区经典集群，那么必须针对 IBM Cloud 基础架构帐户启用虚拟路由器功能 (VRF)，从而使工作程序节点可以在专用网络上相互通信。 要启用 VRF，请参阅 启用 VRF。 要检查是否已启用 VRF，请使用 ibmcloud account show 命令。 如果无法或不想启用 VRF，请启用 VLAN 生成。 要执行此操作，您需要获得“网络”>“管理网络 VLAN 跨基础结构”权限，或请求账户所有者启用该权限。 要检查 VLAN spanning 是否已启用，请使用 ibmcloud oc vlan spanning get --region <region> 命令。

为帐户启用 VRF 或 VLAN 生成时，将除去集群的网络分段。

查看下表，以了解有关为帐户启用了 VRF 或 VLAN 生成时如何实现网络分段的选项。

网络分段选项
安全功能 描述
使用 Calico 设置定制网络策略 可以使用内置 Calico 接口为工作程序节点设置定制 Calico 网络策略。 例如，可以针对特定 pod 或服务，允许或阻止特定网络接口上的网络流量。 要设置自定义网络策略，必须 安装 calicoctl CLI。
对 IBM Cloud 网络防火墙的支持 Red Hat OpenShift on IBM Cloud 与所有 IBM Cloud 防火墙产品兼容。 例如，可以使用定制网络策略来设置防火墙，以便为标准集群提供专用网络安全性，检测网络侵入并进行补救。 例如，您可以选择设置虚拟路由器设备以充当防火墙并阻止不需要的流量。 设置防火墙时，还必须为每个区域打开必需的端口和 IP 地址，以便主节点和工作程序节点可以通信。

我还能做些什么来减少经典集群遭受外部攻击的可能性？

公共公开的应用程序或工作程序节点越多，为阻止外部恶意攻击而必须执行的步骤就越多。 请查看下表，以查找有关如何使应用程序和工作程序节点保持专用的选项。

专用服务和工作程序节点选项
安全功能 描述
限制公开的应用程序数 缺省情况下，在集群中运行的应用程序和服务无法通过公用因特网访问。 您可以选择是要向公众公开应用程序，还是希望应用程序和服务仅可在专用网络上访问。 使服务和应用程序保持专用时，可以利用内置安全功能来确保工作程序节点与 pod 之间的安全通信。 要将服务和应用程序公开到公共互联网，您可以使用 Red Hat OpenShift 路由，或利用 NLB 和 Ingress ALB 支持 安全地公开您的服务。 确保仅公开必要的服务，并定期重新访问已公开应用程序的列表，以确保这些应用程序仍然有效。
使用边缘节点限制公用因特网连接 每个工作程序节点都会配置为接受应用程序 pod 及关联的负载均衡器或 Ingress pod。 您可以将工作者节点标记为 边缘节点，以强制负载平衡器 pod 只部署到这些工作者节点。 此外，您还可以 对工作节点进行标记，这样应用程序 pod 就无法调度到边缘节点上。 利用边缘节点，可以将网络工作负载隔离在集群中更少的工作程序节点上，并使集群中的其他工作程序节点保持专用。

如果我想将群集连接到内部数据中心，该怎么办？

要将工作程序节点和应用程序连接到内部部署的数据中心，您可以使用 strongSwan 服务、Virtual Router Appliance 或 FortiGate Security Appliance 来配置 VPN IPSec 端点。

VPC 集群的网络分段和隐私

要保护网络并限制在授予网络访问权后用户可能造成的损害范围，您必须确保尽可能隔离工作负载，并且限制公共公开的应用程序和工作程序节点的数量。

我的 VPC 集群默认允许哪些网络流量？

缺省情况下，工作程序节点仅连接到专用网络上的 VPC 子网，并且没有公用网络接口。 您的工作节点的所有公共入口都被阻止。 仅当工作程序连接到具有公共网关的 VPC 子网时，才允许来自工作程序节点的公共出口。

要在未连接到 VPC 专用网络的情况下访问缺省 Red Hat OpenShift 组件 (例如，Web 控制台或 OperatorHub )，必须将 公共网关 连接到工作程序节点所部署到的 VPC 子网。 对于连接有公共网关的子网上的工作程序节点，允许其所有流出流量，但仍会阻止所有流入流量。

如果在集群中部署必须从因特网接收流量请求的应用程序，那么可以创建 VPC 负载均衡器来公开应用程序。 要允许流入应用程序的网络流量，必须为要接收的流入网络流量配置 VPC 负载均衡器。

缺省情况下，安全组将应用于 VPC 实例和 VPC ALB。 有关更多信息，请参阅 使用 VPC 安全组控制流量。

什么是网络分段，如何为 VPC 集群设置网络分段？

网络分段描述了用于将网络划分为多个子网的方法。 您可以对要由组织中特定组访问的应用程序和相关数据分组。 在一个子网络中运行的应用程序无法看到或访问另一个子网络中的应用程序。 网络分段还会限制提供给内部人员或第三方软件的访问权，并且可以限制恶意活动的范围。

Red Hat OpenShift on IBM Cloud IBM Cloud VPC 子网，确保高质量的网络性能和工人节点的网络隔离。 VPC 子网包含指定的专用 IP 地址范围（CIDR 块），并将一组工作程序节点和 pod 视为连接到同一物理连线那样进行配置。 VPC 子网专用于您的 IBM Cloud 帐户，而不是在 IBM 客户之间共享。

VPC 子网提供了一个通道，用于连接集群内的工作程序节点。 任何连接到同一 VPC 中任何专用子网的系统都可以与工作程序进行通信。 例如，一个 VPC 中的所有子网都可以通过专用第 3 层路由与内置 VPC 路由器进行通信。 如果集群不需要通信，则可以通过在单独的 VPC 中创建集群来实现最佳的网络分段。 如果您有多个集群必须相互通信，那么可以在同一 VPC 中创建这些集群。 虽然一个 VPC 中的子网可以由该 VPC 中的多个集群共享，但通过将不同的子网用于一个 VPC 中的各个集群，可以实现更好的网络分段。

要在帐户的 VPC 子网之间实现进一步的专用网络分段，可以使用 VPC 访问控制表 (ACL) 来设置定制网络策略。 创建 VPC 时，会以 allow-all-network-acl-<VPC_ID> 格式为 VPC 创建默认 ACL。 缺省情况下，在 VPC 中创建的任何子网都会连接到此 ACL。 ACL 包含入站规则和出站规则，用于允许一个子网上的工作程序节点与同一 VPC 中的子网上任何系统之间的所有流量。 如果要指定允许流至 VPC 子网上工作程序节点的专用网络流量，那么可以为 VPC 中的每个子网创建定制 ACL。 例如，可以创建一组 ACL 规则来阻止集群的大多数入站和出站专用网络流量，同时允许集群正常运行所需的通信。

我还能做些什么来减少 VPC 群集遭受外部攻击的可能性？

公共公开的应用程序或工作程序节点越多，为阻止外部恶意攻击而必须执行的步骤就越多。 请查看下表，以查找有关如何使应用程序和工作程序节点保持专用的选项。

VPC 网络安全选项
安全功能 描述
限制公开的应用程序数 缺省情况下，在集群中运行的应用程序和服务无法通过公用因特网访问。 您可以选择是要向公众公开应用程序，还是希望应用程序和服务仅可在专用网络上访问。 使服务和应用程序保持专用时，可以利用内置安全功能来确保工作程序节点与 pod 之间的安全通信。 要将服务和应用程序公开到公用因特网，可以利用 VPC 负载均衡器和 Ingress ALB 支持来安全地使服务公共可用。 确保仅公开必要的服务，并定期重新访问已公开应用程序的列表，以确保这些应用程序仍然有效。
将公用网络流量限制为流出到使用公共网关的一个子网 如果工作程序节点上的 pod 需要连接到公共外部端点，那么可以将公共网关连接到这些工作程序节点所在的子网。

根据要将工作程序节点连接到的网络，可以选择 VPN 解决方案。

通过路由安全地公开应用程序

如果您想允许从互联网传入网络流量，可以使用路由来暴露您的应用程序。

每个 Red Hat OpenShift 集群都会自动设置一个 Red Hat OpenShift 路由器，该路由器被分配了一个唯一的域名，并使用 TLS 证书进行加密。 使用路由公开应用程序时，您的应用程序会从 Red Hat OpenShift 路由器分配一个 URL。

为应用程序创建路径时，可以决定是创建安全 (HTTPS) 还是不安全 (HTTP) 路径。 对于安全路径，可以决定要在哪里实现 TLS 终止，例如在路由器或 pod 上。 有关更多信息，请参阅使用路径公开应用程序。

利用 LoadBalancer 和 Ingress 服务安全地公开应用程序

可以使用网络负载均衡器 (NLB) 和 Ingress 应用程序负载均衡器 (ALB) 联网服务将应用程序连接到公用因特网或外部专用网络。 请查看 NLB 和 ALB 的以下可选设置，您可以使用这些设置来满足后端应用程序安全需求，或者可以对流过集群的流量进行加密。

能否使用安全组来管理群集的网络流量？

经典集群：IBM Cloud 安全组会应用于单个虚拟服务器的网络接口，以过滤系统管理程序级别的流量。 如果要管理每个工作程序节点的流量，可以使用安全组。 创建安全组时，必须允许 VRRP 协议，Red Hat OpenShift on IBM Cloud 使用此协议来管理 NLB IP 地址。 要在所有工作节点上统一管理群集的流量，可使用 Calico 和 Kubernetes 策略。

VPC 群集：VPC 安全组应用于单个虚拟服务器的网络接口，以便在管理程序级别过滤流量。 您可以将入站和出站规则添加到集群的缺省安全组，以管理到 VPC 集群的入站和出站流量。 有关安全组的更多信息 (包括缺省设置)，请参阅 使用 VPC 安全组控制流量。

由于 VPC 集群的工作程序节点存在于服务帐户中，并且未在 VPC 基础结构仪表板中列出，因此无法创建安全组并将其应用于工作程序节点实例。 您只能修改为您创建的现有安全组。

如何使用 LoadBalancer 和入口服务终止 TLS？

Ingress 服务在流量流中的两个点提供 TLS 终止：

  • 到达时解密软件包：默认情况下，Ingress ALB 负载均衡 HTTP 网络流量到群集中的应用程序。 要同时对入局 HTTPS 连接进行负载均衡，可以配置 ALB 来解密网络流量，然后将已解密的请求转发到集群中公开的应用程序。 如果使用的是 IBM 提供的 Ingress 子域，那么可以使用 IBM 提供的 TLS 证书。 如果您使用定制域，那么可以使用自己的 TLS 证书来管理 TLS 终止。
  • 在将包转发到上游应用程序之前重新加密包：ALB 在将流量转发到应用程序之前解密 HTTPS 请求。 如果您具有需要 HTTPS 的应用程序，并且在将流量转发到这些上游应用程序之前需要对流量进行加密，那么可以使用 ssl-services 注释。 如果上游应用程序可以处理 TLS，那么可以选择提供单向或双向认证 TLS 私钥中包含的证书。

持久性存储器

查看用于加密和保护 IBM Cloud 中持久性存储器上数据的受支持选项。

缺省情况下，所有 IBM Cloud 存储解决方案都使用 IBM 管理的加密密钥自动对静态数据加密，而不会产生额外成本。 有关更多信息，请参阅以下链接。

根据选择的存储器类型，可以通过 IBM Key Protect 设置其他加密，以使用您自己的加密密钥来保护动态和静态数据。

您还可以使用 IBM Cloud 数据库服务（如 IBM Cloudant NoSQL DB）在集群外部的受管数据库中持久存储数据。 通过云数据库服务存储的数据可以跨集群、专区和区域进行访问。 有关与安全性相关的信息，请参阅特定于数据库服务的 IBM Cloud 文档。

监视和日志记录

检测集群中恶意攻击的关键是正确监视和记录度量值以及集群中发生的所有事件。 监视和日志记录还可帮助您了解应用程序的集群容量和资源可用性，以便您可以相应地进行规划，避免应用程序产生停机时间。

IBM 是否监控我的群集？
IBM 持续监视每个集群主节点，以控制和补救进程级别的拒绝服务 (DOS) 攻击。Red Hat OpenShift on IBM Cloud 会自动扫描部署了主节点的每个节点，以查找在 Kubernetes，Red Hat OpenShift和特定于操作系统的安全修订中找到的漏洞。 如果找到了漏洞，Red Hat OpenShift on IBM Cloud 会自动代表用户应用修订并解决漏洞，以确保保护主节点。
记录了哪些信息?
默认情况下，Red Hat OpenShift on IBM Cloud 会自动收集以下群集组件的日志：
  • 容器：写入 STDOUT 或 STDERR 的日志。
  • 应用程序：写入应用程序中特定路径的日志。
  • 工作程序：Red Hat Enterprise Linux 操作系统中发送到 /var/log/syslog 和 /var/log/auth.log 的日志。
  • Red Hat OpenShift API 服务器：出于审计原因，发送到 API 服务器的每个与群集相关的操作都会被记录下来，包括时间、用户和受影响的资源。Red Hat OpenShift 更多信息，请参阅 Kubernetes 审计日志。 您可以使用 IBM Cloud Logs 来访问这些日志。 有关更多信息，请参阅入门教程。
  • 路由器：记录路径上的入站网络流量。
  • Kubernetes 系统组件：kubelet、kube-proxy 和在 kube-system 名称空间中运行的其他组件的日志。

要访问集群组件的日志，请设置 IBM Cloud Logs。IBM Cloud Logs 可访问您的所有日志，您还可以汇总日志，并跨多个集群构建自定义视图。

如何监控群集的健康状况和性能？
可以通过在 Red Hat OpenShift on IBM Cloud 控制台或 CLI 中监视集群组件和计算资源（例如，CPU 和内存使用情况）来验证应用程序、服务和工作程序节点的运行状况、容量和性能。 要查看群集更深入的指标，可以使用基于开源技术的内置监控功能，如 Prometheus 和 Grafana。 创建集群时会自动安装 Prometheus，您可以使用该工具来访问实时集群和应用程序度量值。 Prometheus 度量值不会持久存储。 要访问历史指标和比较多个群集的指标，请使用 IBM Cloud Monitoring 来代替。

要建立基于主机的入侵检测系统 (HIDS) 和安全事件日志监控 (SELM)，可安装专门用于监控群集和容器化应用程序以检测入侵或滥用的第三方工具，如 Twistlock 或 Sysdig Falco 项目。

如何审计群集中发生的事件？
可以在 IBM Cloud® Activity Tracker 集群中设置 Red Hat OpenShift on IBM Cloud。 有关更多信息，请查看 Activity Tracker 文档。
要在群集中启用信任，我有哪些选择？
缺省情况下，Red Hat OpenShift on IBM Cloud 提供了许多集群组件功能，以便您可以在高度安全的环境中部署容器化应用程序。 扩展集群中的信任级别，以更好地确保集群中发生的情况符合您的意图。 可以通过各种方式在集群中实现信任，如下图中所示。

部署具有可信内容的容器。
使用可信内容部署容器

  1. 映像的内容信任：通过在 IBM Cloud Container Registry 中启用内容信任来确保映像的完整性。 通过可信内容，可以控制谁可以将映像签名为可信。 在可信签署者将映像推送到注册表之后，用户可以拉取已签名的内容，以便可以验证映像的源。 有关更多信息，请参阅对可信内容的映像签名。

  2. 容器映像安全强制：使用具有自定义策略的接纳控制器，以便在部署容器映像之前对其进行验证。 通过诸如 Portieris 之类的容器映像安全实施项目，您可以控制映像的部署位置，并确保它们满足 内容信任 需求。 如果部署不满足设置的策略，那么强制实施的安全性会阻止对集群进行修改。

  3. 映像漏洞扫描程序：缺省情况下，Vulnerability Advisor 会扫描存储在 IBM Cloud Container Registry 中的映像，以查找潜在的安全漏洞。 有关更多信息，请参阅使用 Vulnerability Advisor 管理映像安全性。

  4. IBM Cloud Security and Compliance Center: 启用 IBM Cloud Security and Compliance Center时，可以查看有关可疑传入和传出网络流量的报告。 有关更多信息，请参阅 什么是 IBM Cloud Security and Compliance Center?。

  5. IBM Cloud® Secrets Manager: 您可以将 Ingress 和 Kubernetes 私钥存储在 IBM Cloud® Secrets Manager中。 将 Secrets Manager 集成到集群时，将设置缺省 Secrets Manager 实例，其中上载了所有 Ingress 子域私钥。 有关更多信息，请参阅 在 Kubernetes Service 集群中设置 Secrets Manager。

容器运行时

工作程序节点随 CRI-O 一起安装，作为容器运行时接口，受 Security-Enhanced Linux(SELinux) 标记系统保护。

当使用 Kubernetes 与容器映像交互（例如创建 pod）时，kubelet 会通过 UNIX 套接字 crio.sock 与 CRI-O 通信。 UNIX 套接字使用下表中的 SELinux 标签来执行相应的系统访问策略。 这些标签使用户容器无法访问容器运行时套接字。

用于保护容器运行时进程的 SELinux 标签。
进程 SELinux 标签
CRI-O system_u:system_r:container_runtime_t:s0
kubelet system_u:system_r:unconfined_service_t:s0
crio.sock system_u:object_r:container_var_run_t:s0
容器进程，例如 c14 system_u:system_r:container_t:s0:c14

示例请求流

下图显示了 kubelet 与 CRI-O之间的示例请求流。

kubelet 与 CRI-O之间的示例请求流。
之间的请求流示例 CRI-O

映像和注册表

每个部署都基于一个映像，映像用于保存有关如何启动运行应用程序的容器的指示信息。 这些指示信息包括容器内的操作系统以及要安装的额外软件。 要保护应用程序，必须保护映像并建立确保映像完整性的检查。

我应该使用公共注册表还是私人注册表来存储图像？
开始使用 Docker 映像和 Kubernetes 在集群中创建第一个容器化应用程序时，可以使用公共注册表（如 Docker Hub）。 但是，对于企业应用程序，请避免使用您不了解或不信任的注册表，以保护集群免受恶意映像的损害。 将图像保存在专用注册表中，如 IBM Cloud Container Registry 中提供的注册表或 Red Hat OpenShift 集群中自动设置的 内部注册表，并确保控制对注册表和可推送图像内容的访问。
为什么必须检查图像是否存在漏洞？
研究显示，大多数恶意攻击利用的是已知软件漏洞和薄弱的系统配置。 基于映像部署容器时，容器将使用在映像中描述的操作系统和额外的二进制文件启动。 就像保护虚拟机或物理机器一样，您必须消除在容器内使用的操作系统和二进制文件中的已知漏洞，以保护应用程序不被未经授权的用户访问。

要保护应用程序，请考虑解决以下方面的问题：

  1. 自动构建流程并限制权限：根据源代码自动构建容器镜像，消除源代码差异和缺陷。 通过将构建过程集成到 CI/CD 管道中，可以确保仅当映像通过了指定的安全检查时，才会扫描和构建映像。 为了避免开发者将最新修订程序应用于敏感映像，请限制组织中有权访问构建过程的人员数。

  2. 在部署到生产环境之前扫描映像： 确保在部署容器前扫描每个映像。 例如，如果使用 IBM Cloud Container Registry，那么在将映像推送到名称空间时，会自动扫描所有映像以查找漏洞。 如果发现漏洞，请考虑消除漏洞或阻止部署这些映像。 在组织中查找负责监视和除去漏洞的人员或团队。 根据组织结构，此人可能属于安全团队、操作团队或部署团队。 启用 内容信任，以便映像必须由可信签署者核准，然后才能将其推送到容器注册表。 然后，安装开放式源代码 Portieris 项目 许可控制器，以阻止来自未签名映像的容器部署。

  3. 定期扫描运行中的容器：. 即使基于通过漏洞检查的映像部署了容器，容器中运行的操作系统或二进制文件也可能会随时间推移而变得有漏洞。 要保护应用程序，必须确保定期扫描运行中的容器，以便可以检测到漏洞并进行补救。 根据应用程序的不同，为了增加额外的安全性，您可以建立一个任务，在检测到易受攻击的容器后将其删除。

可以使用内置容器注册表来自动执行从外部源存储库中的源代码到内部注册表的容器映像构建过程。 但是，将映像推送到内部注册表时，不会自动扫描映像是否有漏洞。 要设置映像扫描，请改为设置注册表名称空间，然后将映像推送到受管的 IBM Cloud Container Registry。

映像和部署的安全性
安全功能 描述
IBM Cloud Container Registry中受保护的 Docker 专用映像存储库 在由 IBM托管和管理的多租户，高可用性且可扩展的专用映像注册表中设置您自己的 Docker 映像存储库。 通过使用注册表，可以在集群用户之间构建，安全地存储和共享 Docker 映像。/n 在使用容器映像时，了解有关 保护个人信息 的更多信息。
仅推送具有可信内容的映像 通过在映像存储库中启用 内容信任 来确保映像的完整性。 通过可信内容，可以控制谁可以将映像签名为可信，并将映像推送到特定注册表名称空间。 受信任的签名者将图像推送到注册表命名空间后，用户可以提取签名内容，从而验证图像的发布者和完整性
自动漏洞扫描 使用 IBM Cloud Container Registry时，可以利用 Vulnerability Advisor 提供的内置安全扫描。 对于推送到注册表名称空间的每个映像，都会自动根据包含已知 CentOS、Debian、Red Hat 和 Ubuntu 问题的数据库进行扫描以确定是否有漏洞。 如果发现漏洞，Vulnerability Advisor 会提供如何解决这些问题的说明，以确保图像的完整性和安全性
阻止来自易受攻击映像或不可信用户的部署 使用定制策略创建许可控制器，以便您可以在部署容器映像之前对其进行验证。 通过 开放式源代码 Portieris 项目，您可以控制从何处部署映像，并确保这些映像满足内容信任需求。 如果某个部署不符合您设置的策略，接纳控制器就会阻止群集中的部署
我有哪些选项可以扫描运行中的容器是否存在漏洞？
您可以在集群中安装第三方解决方案，例如 Twistlock 或 StackRox，以扫描正在运行的容器并在检测到恶意活动时阻止这些活动。

容器隔离和安全性

在集群中运行多个应用程序时，您希望确保工作负载彼此隔离运行，并限制集群中 pod 的许可权，以避免嘈杂的邻居或拒绝服务攻击。

什么是 Red Hat OpenShift 项目，为什么要使用它？
Red Hat OpenShift 项目是一种对集群进行虚拟分区的方法，可为您的部署和希望将其工作负载转移到集群上的用户组提供隔离。 通过项目，可以跨工作程序节点以及跨多专区集群中的专区组织资源。
每个群集都会设置一套默认的 Red Hat OpenShift 项目，其中包括 Red Hat OpenShift on IBM Cloud 正常运行和管理群集所需的部署和服务。 有关更多信息，请参阅服务体系结构。
集群管理员自动有权访问这些项目，并可以在集群中设置其他项目。 此外，被授予集群访问权的集群用户可以创建自己的项目，并且作为项目的创建者，可以使用管理员许可权来管理该项目。 不过，群集用户默认情况下不能访问其他项目，除非群集管理员授予他们访问权限。

对于群集中的每个项目，确保设置适当的 RBAC 策略，以限制对该项目的访问、控制部署内容，并设置适当的 资源配额和限制范围。

我应该建立单租户还是多租户集群？

在单租户集群中，将为必须在集群中运行工作负载的每组人员创建一个集群。 通常，此团队负责管理集群并正确配置和保护集群。 多租户集群使用多个项目来隔离租户及其工作负载。

决定是单租户集群还是多租户集群。
单租户与多租户集群

决定是使用单租户集群还是多租户集群取决于必须在集群中运行工作负载的团队数量、其服务需求、服务大小以及要为工作负载实现的隔离级别。

如果您有很多具有复杂服务的团队，并且每个团队都必须控制集群的生命周期，那么单租户集群可能是适合您的选项。 这包括有权决定何时更新集群，或者可以将哪些资源部署到集群。 您还可以配置单租户集群以允许使用特权 pod，而不会使其他租户面临泄露风险。 请记住，管理集群需要深入的 Kubernetes、Red Hat OpenShift 和基础架构知识，以确保集群容量和部署的安全性。

多租户集群使用 Red Hat OpenShift 项目来隔离租户，通常由不属于某个租户的独立团队进行管理。 如果您有多个团队必须在一个集群中运行多个小型工作负载，并且创建在多个专区中高度可用的单租户集群不会带来您需要的成本效益，那么多租户集群可能是适合您的选项。 虽然多租户集群通常需要较少的人员来管理集群，但这种集群可能无法提供您需要的隔离级别，并在以下方面增加更多复杂性：

  • **访问权：**设置多个项目时，必须为每个项目配置正确的 RBAC 策略，以确保资源隔离。 RBAC 策略较为复杂，需要掌握深厚的 Kubernetes 知识。
  • **特权 pod：**如果多租户集群中有一个租户需要运行特权 pod，那么此 pod 可以访问集群中的其他项目或损坏共享计算主机。 控制特权 pod 是一项复杂的任务，需要大量工作和深入的技术专业知识。 使用 安全上下文约束(SCC) 来控制租户可以在集群中部署的资源。
  • 网络策略： 由于工作节点连接到同一个专用网络，因此必须确保制定严格的网络策略，防止 pod 访问其他命名空间中的 pod。
  • 计算资源限制： 为确保每个团队都有必要的资源在群集中部署服务和运行应用程序，必须为每个命名空间设置 资源配额。 资源配额决定了部署限制，如可部署的 Kubernetes 资源数量，以及这些资源可消耗的 CPU 和内存数量。 设置配额后，用户必须在其部署中包含资源请求和限制。
  • 共享群集资源： 如果在一个群集中运行多个租户，那么某些群集资源（如 Red Hat OpenShift 路由器、Ingress 应用程序负载平衡器 (ALB) 或可用的可移植 IP 地址）将在租户之间共享。 如果较小的服务必须与集群中的大型服务竞争资源，那么较小的服务要使用共享资源可能很难。
  • 更新： 一次只能运行一个 Red Hat OpenShift API 版本。 集群中运行的所有应用程序都必须遵守当前的 Red Hat OpenShift API 版本，与拥有应用程序的团队无关。 要更新群集时，必须确保所有团队都已准备好切换到新的 Red Hat OpenShift API 版本，并对应用程序进行相应更新。 这也意味着，各个团队对其希望运行的 Red Hat OpenShift API 版本的控制能力较弱。
  • **集群设置中的更改：**如果要更改集群设置或将工作负载重新安排到新工作程序节点上，必须对各租户应用此更改。 相比单租户集群，这种应用需要更多的协调和测试。
  • **通信过程：**管理多个租户时，请考虑设置通信过程，以便租户知道集群中存在问题时或者需要为其服务提供更多资源时应求助于何处。 此通信过程还包括向租户通知集群设置或计划更新中的所有更改。

虽然单租户集群和多租户集群的成本大致相同，但单租户集群提供的隔离级别高于多租户集群中项目的隔离级别。 要更好地隔离工作负载，请使用单租户集群。

Kubernetes 网络策略 保护 pod 免受内部网络流量的影响。 例如，如果大多数或所有 pod 不需要访问特定 pod 或服务，并且您希望确保缺省情况下 pod 无法访问这些 pod 或服务，那么可以创建 Kubernetes 网络策略来阻止流入这些 pod 或服务的流量。 Kubernetes 网络策略还可以通过控制不同名称空间中的 pod 和服务之间的通信方式来帮助您实施名称空间之间的工作负载隔离。

如何控制 pod 权限？
为了控制项目内或项目间的 pod 许可权，Red Hat OpenShift on IBM Cloud 使用安全上下文约束 (SCC)。 默认情况下，每个集群都设置了 Red Hat OpenShift SCC 和一组 IBM 提供的 SCC，您可以将这些 SCC 分配给服务帐户、pod、部署或项目，以限制集群内的权限。 如果未显式分配 SCC，那么 pod 将使用 restricted SCC。Red Hat OpenShift SCC 比社区 Kubernetes 集群中的缺省 pod 安全策略更严格。 您可能需要修改在社区 Kubernetes 集群中运行的应用程序，以便该应用程序可以在 Red Hat OpenShift 中运行。 有关更多信息，请参阅配置安全上下文约束。
我还能做些什么来保护我的集装箱？
限制特权容器的数量。 容器在与其他进程隔离的计算主机上作为单独的 Linux 进程运行。 虽然用户在容器内具有 root 用户访问权，但在容器外部此用户的许可权受限，以保护其他 Linux 进程、主机文件系统和主机设备。 某些应用程序需要对主机文件系统的访问权，或者需要高级许可权才能正常运行。 您可以通过特权方式运行容器，以允许容器与计算主机上运行的进程具有相同的访问权。
请记住，特权容器在遭到破坏时，可能会对集群和底层计算主机造成巨大损害。 请尝试限制以特权方式运行的容器数，并考虑更改应用程序的配置，以便应用程序可以在没有高级许可权的情况下运行。

如果要阻止特权容器在集群中运行，请考虑设置定制安全上下文约束。

将操作系统安全设置应用于 pod
您可以自定义默认 安全上下文约束，以控制可在容器内运行的用户 ID 和组 ID，或拥有卷挂载路径的用户 ID 和组 ID。 设置特定用户标识有助于简化最低特权模型。 如果安全上下文未指定用户，那么 Kubernetes 会自动使用容器映像中指定的用户。 有关更多信息，请参阅配置安全上下文约束。
设置容器的 CPU 和内存限制
每个容器都需要特定的 CPU 数和内存量才能正确启动并继续运行。 您可以为容器或 pod 定义“限制范围”，以限制它们可以消耗的 CPU 和内存量。 如果未设置 CPU 和内存的限制，并且容器处于繁忙状态，那么容器将使用所有可用的资源。 这种对资源的高消耗可能会影响工作者节点上的其他容器，因为它们没有足够的资源来正常启动或运行，并使工作者节点面临拒绝服务攻击的风险。

存储个人信息

您负责确保 Kubernetes 资源和容器映像中个人信息的安全性。 个人信息包括您的姓名、地址、电话号码或电子邮件地址，或者包括可能识别、联系或查找到您、您的客户或其他任何人的其他信息。

使用 Kubernetes 私钥存储个人信息

将个人信息仅存储在设计为保存个人信息的 Kubernetes 资源中。 例如，不要在 Red Hat OpenShift 项目、部署、服务或配置映射的名称中使用自己的名字。 为了获得正确的保护和加密，请改为将个人信息存储在 私钥 中。

要在应用程序运行时集中管理集群和注入中的所有私钥，请尝试 IBM Cloud Secrets Manager。

使用 Kubernetes imagePullSecret 存储映像注册表凭证

请勿在容器映像或注册表名称空间中存储个人信息。 为获得适当的保护和加密，请将注册表凭据存储在 Kubernetes imagePullSecrets 中，而将其他个人信息存储在 秘密中。 请记住，如果个人信息存储在先前的映像层中，那么删除映像可能不足以删除这些个人信息。

Kubernetes 安全公告

如果在 Kubernetes 中发现漏洞，Kubernetes 会在安全公告中发布 CVE 以通知用户，并描述用户必须执行哪些操作来修复漏洞。 影响 Red Hat OpenShift on IBM Cloud 用户或 IBM Cloud 平台的 Kubernetes 安全公告会在 IBM Cloud 安全公告中发布。

有些 CVE 需要 Red Hat OpenShift 版本的最新补丁更新，您可以将其作为 Red Hat OpenShift on IBM Cloud 中常规 群集更新流程 的一部分进行安装。 确保及时应用安全补丁，以保护集群免受恶意攻击。 有关安全补丁包含哪些内容的详细信息，请参阅 Red Hat OpenShift on IBM Cloud 版本信息。