支持控制台（Console）开发人员开始试用联系人

17.4. 安全性

17.4.1. 安全基础知识
复制链接

安全性是 OpenShift Container Platform 上电信部署的关键组件，特别是在运行云原生网络功能(CNF)时。

您可以考虑关键安全考虑，在电信(telco)环境中增强高带宽网络部署的安全性。通过实施这些标准和最佳实践，您可以在特定电信用例中增强安全性。

17.4.1.1. RBAC 概述
复制链接

基于角色的访问控制 (RBAC) 对象决定是否允许用户在项目内执行给定的操作。

集群管理员可以使用集群角色和绑定来控制谁对 OpenShift Container Platform 平台本身和所有项目具有各种访问权限等级。

开发人员可以使用本地角色和绑定来控制谁有权访问他们的项目。请注意，授权是与身份验证分开的一个步骤，身份验证更在于确定执行操作的人的身份。

授权使用以下授权对象来管理：

规则
是特定对象允许的操作集合。例如，规则可以确定用户或服务帐户是否可以创建 pod。每个规则都指定一个 API 资源、该 API 中的资源以及允许的操作。
角色

是定义用户或组能够执行的操作的集合。您可以将规则关联或绑定到多个用户或组。角色文件可以包含一个或多个规则，用于指定该角色允许的操作和资源。

角色被归类为以下类型：

  • 集群角色：您可以在集群级别定义集群角色。它们不与单个命名空间有固定的关联。当您将命名空间或特定命名空间绑定到用户、组或服务帐户时，它们可以在所有命名空间或特定命名空间中应用。
  • 项目角色：您可以在特定命名空间中创建项目角色，它们仅应用到该命名空间。您可以为特定用户分配权限，在其命名空间中创建角色和角色绑定，确保它们不会影响其他命名空间。
绑定

是用户和/或组与角色之间的关联。您可以创建角色绑定，将角色中的规则连接到特定的用户 ID 或组。这会合并角色和用户或组，定义他们可以执行的操作。

注意

您可以将多个角色绑定到用户或组。

如需有关 RBAC 的更多信息，请参阅"使用 RBAC 来定义和应用权限"。

操作 RBAC 注意事项

要减少操作开销，务必要通过组来管理访问，而不是在多个集群中处理单个用户 ID。通过管理机构级别的组，您可以简化访问控制并简化整个机构的管理。

17.4.1.2. 安全帐户概述
复制链接

服务帐户是一种 OpenShift Container Platform 帐户，它允许组件直接访问 API。服务帐户是各个项目中存在的 API 对象。服务帐户为控制 API 访问提供了灵活的方式，不需要共享常规用户的凭证。

您可以使用服务帐户将基于角色的访问控制(RBAC)应用到 pod。通过将服务帐户分配给工作负载，如 pod 和部署，您可以授予其他权限，如从不同的 registry 中拉取。这也允许您为服务帐户分配较低的特权，从而减少在它们下运行的 pod 的安全占用空间。

有关服务帐户的更多信息，请参阅"了解和创建服务帐户"。

17.4.1.3. 身份提供程序配置
复制链接

配置身份提供程序是在集群中设置用户的第一步。您可以使用身份提供程序在机构级别管理组。

身份提供程序可以拉取在机构级别维护的特定用户组，而不是集群级别。这可让您按照机构建立的做法，从组中添加或删除用户。

注意

您必须设置一个 cron 作业，以便频繁地运行才能将任何更改提取到集群中。

您可以使用身份提供程序来管理机构中特定组的访问权限级别。例如，您可以执行以下操作来管理访问级别：

  • 将 cluster-admin 角色分配给需要集群级别权限的团队。
  • 授予应用管理员特定特权，以仅管理其各自的项目。
  • 为运维团队提供跨集群的 view 访问权限，以便在不允许修改的情况下启用监控。

有关配置身份提供程序的详情，请参考 "Understanding identity provider configuration"。

默认在每个集群中都创建具有 cluster-admin 特权的 kubeadmin 用户。要增强集群安全性，您可以将 'kubeadmin' 用户替换为 cluster-admin 用户，然后禁用或删除 kubeadmin 用户。

先决条件

  • 您已创建了具有 cluster-admin 特权的用户。
  • 已安装 OpenShift CLI(oc)。
  • 您有管理对虚拟密码库的访问权限，以进行安全存储。

流程

  1. 使用 htpasswd 身份提供程序创建紧急的 cluster-admin 用户。如需更多信息，请参阅"About htpasswd 身份验证"。

  2. 运行以下命令，为新用户分配 cluster-admin 权限： 

    $ oc adm policy add-cluster-role-to-user cluster-admin <emergency_user>

  3. 验证紧急用户访问：

    1. 使用新的紧急用户登录到集群。

    2. 运行以下命令确认用户具有 cluster-admin 权限： 

      $ oc whoami

      确保输出显示紧急用户的 ID。

  4. 将紧急用户的密码或身份验证密钥安全地存储在虚拟密码库中。

    注意

    按照您的机构的最佳实践保护敏感凭证。

  5. 运行以下命令禁用或删除 kubeadmin 用户，以降低安全风险： 

    $ oc delete secrets kubeadmin -n kube-system

17.4.1.5. 电信 CNFs 的安全注意事项
复制链接

电信工作负载处理大量敏感数据，需要高可靠性。单个安全漏洞可能会导致集群范围的破坏。当许多组件在单节点 OpenShift 集群上运行时，必须保护每个组件，以防止任何违反行为。确保整个基础架构中的安全性（包括所有组件）对于保持电信网络的完整性和避免漏洞至关重要。

以下关键安全功能对于电信至关重要：

  • 安全性上下文约束(SCC)：提供对 OpenShift 集群中 pod 安全性的粒度控制。
  • Pod Security Admission (PSA)：Kubernetes 原生 pod 安全控制。
  • 加密：确保数据在高吞吐量中的网络环境中保密性。

Kubernetes 最初有有限的 pod 安全性。当 OpenShift Container Platform 集成 Kubernetes 时，红帽通过安全性上下文约束(SCC)添加了 pod 安全性。在 Kubernetes 版本 1.3 中，PodSecurityPolicy (PSP)作为类似的功能引入。但是，Pod Security Admission (PSA)在 Kubernetes 版本 1.21 中引入，这会导致在 Kubernetes 版本 1.25 中弃用 PSP。

在 OpenShift Container Platform 版本 4.11 中也提供了 PSA。虽然 PSA 提高了 pod 安全性，但它缺少在电信用例中仍需要的 SCC 提供的一些功能。因此，OpenShift Container Platform 继续支持 PSA 和 SCC。

17.4.1.7. CNF 部署的主要区域
复制链接

云原生网络功能(CNF)部署包含以下关键区域：

Core
CNF 的第一个部署发生在无线网络的核心中。在核心中部署 CNF 通常意味着位于中央办事处或数据中心的服务器机架。这些服务器同时连接到互联网和 Radio 访问网络(RAN)，但它们通常位于多个安全防火墙后面，或者有时与互联网断开连接。这种类型的设置称为离线或断开连接的集群。
RAN
在核心网络中成功测试 CNF 并发现它们有效后，它们被视为在 Radio 访问网络(RAN)中部署。在 RAN 中部署 CNF 需要大量服务器（在大型部署中最多 100,000 个）。这些服务器位于接近单元格 towers，通常作为单节点 OpenShift 集群运行，具有高可扩展性的需求。

17.4.1.8. 特定于电信的基础架构
复制链接

硬件要求
在电信网络中，集群主要基于裸机硬件构建。这意味着操作系统(op-system-first)直接安装在物理机上，而无需使用虚拟机。这可减少网络连接复杂性，最小化延迟并优化应用程序的 CPU 使用量。
网络要求
与标准 IT 网络相比，电信网络需要更高的带宽。电信网络通常使用双端口 25 GB 连接或 100 GB 网络接口卡(NIC)来处理大规模数据吞吐量。安全性至关重要，需要加密连接和安全端点来保护敏感的个人数据。

17.4.1.9. 生命周期管理
复制链接

升级对于安全性至关重要。当发现了安全漏洞时，会在最新的 z-stream 版本中修补。然后，通过每个较低 y-stream 版本回滚，直到所有支持的版本都被修补为止。不再支持的发行版本不会接收补丁。因此，定期升级 OpenShift Container Platform 集群非常重要，以保持它们使用受支持的版本，并确保它们保护系统不受安全漏洞的影响。

有关生命周期管理和升级的更多信息，请参阅"升级电信核心 CNF 集群"。

17.4.1.10. 网络功能到 CNFs 的演变
复制链接

网络功能(NF)以物理网络功能(PNF)开始，它们是独立运行的专门构建的硬件设备。随着时间推移，PNF 发展成虚拟网络功能(VNF)，在控制 CPU、内存、存储和网络等资源的同时虚拟化其功能。

随着技术的进一步发展，VNF 过渡到云原生网络功能(CNF)。CNF 在轻量级、安全且可扩展的容器中运行。它们包括了严格的限制，包括非 root 执行和最小的主机干扰，以增强安全性和性能。

PNF 具有非受限的 root 访问权限来独立操作而不会相互影响。随着到 VNF 的转换，对资源的使用会进行控制，但进程仍然可以以 root 用户身份在其虚拟机内运行。相反，CNF 会限制 root 访问权限并限制容器的功能，以防止干扰其他容器或主机操作系统。

迁移到 CNF 的主要挑战如下：

  • 将单体网络功能拆分为较小的容器化进程。
  • 遵循云原生原则，如非 root 执行和隔离，同时保持电信级的性能和可靠性。
Red Hat logoGithubredditYoutubeTwitter

学习

尝试、购买和销售

社区

關於紅帽

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

让开源更具包容性

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

关于红帽文档

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

Legal Notice

Theme

© 2026 Red Hat返回顶部