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
角色分配给需要集群级别权限的团队。 - 授予应用管理员特定特权,以仅管理其各自的项目。
-
为运维团队提供跨集群
的视图
访问权限,以便在不需要修改的情况下启用监控。
有关配置身份提供程序的详情,请参考 "Understanding identity provider configuration"。
其他资源
17.4.1.4. 使用 cluster-admin 用户替换 kubeadmin 用户
默认在每个集群中都创建具有 cluster-admin
特权的 kubeadmin
用户。要增强集群安全性,您可以将 'kubeadmin' 用户替换为 cluster-admin
用户,然后禁用或删除 kubeadmin
用户。
先决条件
-
您已创建了具有
cluster-admin
特权的用户。 -
已安装 OpenShift CLI(
oc
)。 - 您有管理对虚拟密码库的访问权限,以进行安全存储。
流程
-
使用
htpasswd
身份提供程序创建紧急的cluster-admin
用户。如需更多信息,请参阅"About htpasswd 身份验证"。 运行以下命令,为新用户分配
cluster-admin
权限:$ oc adm policy add-cluster-role-to-user cluster-admin <emergency_user>
验证紧急用户访问:
- 使用新的紧急用户登录到集群。
运行以下命令确认用户具有
cluster-admin
权限:$ oc whoami
确保输出显示紧急用户的 ID。
将紧急用户的密码或身份验证密钥安全地存储在虚拟密码库中。
注意按照您的组织的最佳实践保护敏感凭证。
运行以下命令禁用或删除
kubeadmin
用户,以降低安全风险:$ oc delete secrets kubeadmin -n kube-system
其他资源
17.4.1.5. 电信 CNFs 的安全注意事项
电信工作负载处理大量敏感数据,需要高可靠性。单个安全漏洞可能会导致集群范围的破坏。当许多组件在单节点 OpenShift 集群上运行时,必须保护每个组件,以防止任何违反行为。确保整个基础架构中的安全性(包括所有组件)对于保持电信网络的完整性和避免漏洞至关重要。
以下关键安全功能对于电信至关重要:
- 安全性上下文约束(SCC):提供对 OpenShift 集群中 pod 安全性的粒度控制。
- Pod Security Admission (PSA):Kubernetes 原生 pod 安全控制。
- 加密:确保数据在高吞吐量中的网络环境中保密性。
17.4.1.6. Kubernetes 和 OpenShift Container Platform 中 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
- CNFs 的第一个部署发生在无线网络的核心中。在核心中部署 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)。CNFs 在轻量级、安全且可扩展的容器中运行。它们实施字符串限制,包括非 root 执行和最小的主机干扰,以增强安全性和性能。
pNFS 没有受到限制的 root 访问权限,无需干扰。随着对 VNF 的转换,对资源使用量进行了控制,但进程仍然可以以 root 用户身份在虚拟机内运行。相反,CNF 会限制 root 访问权限和限制容器功能,以防止与其他容器或主机操作系统进行干扰。
迁移到 CNF 的主要挑战如下:
- 将单体网络功能拆分为较小的容器化进程。
- 遵循云原生原则,如非 root 执行和隔离,同时保持电信级的性能和可靠性。
17.4.2. 主机安全性
17.4.2.1. Red Hat Enterprise Linux CoreOS (RHCOS)
Red Hat Enterprise Linux CoreOS (RHCOS)与关键领域中的 Red Hat Enterprise Linux (RHEL)不同。如需更多信息,请参阅"About RHCOS"。
从电信角度来看,主要区别是 rpm-ostree
的控制,它通过 Machine Config Operator 更新。
RHCOS 遵循 OpenShift Container Platform 中用于 pod 的不可变设计。这样可确保操作系统在集群中保持一致。有关 RHCOS 架构的详情,请参考 "Red Hat Enterprise Linux CoreOS (RHCOS) "。
要在保持安全性的同时有效地管理主机,请尽可能避免直接访问。反之,您可以使用以下方法进行主机管理:
- debug pod
- 直接 SSH
- 控制台访问
查看以下 RHCOS 保密机制,它们是维护主机安全性不可或缺的:
- Linux 命名空间
- 为进程和资源提供隔离。每个容器都会将其进程和文件保留在其自己的命名空间中。如果用户退出容器命名空间,则他们可能会获得对主机操作系统的访问权限,这可能会受到安全影响。
- Security-Enhanced Linux (SELinux)
强制强制访问控制,以按进程限制对文件和目录的访问。如果进程尝试中断其限制,它会防止未经授权的访问文件,从而添加额外的安全层。
SELinux 遵循拒绝所有内容的安全策略,除非明确允许。如果进程尝试修改或访问没有权限的文件,SELinux 将拒绝访问。如需更多信息,请参阅 SELinux 简介。
- Linux 功能
- 以粒度级别为进程分配特定的特权,从而最大程度减少对完整的 root 权限的需求。如需更多信息,请参阅"Linux 功能"。
- 控制组(cgroups)
- 分配和管理系统资源,如进程和容器的 CPU 和内存,确保有效使用。自 OpenShift Container Platform 4.16 起,有两个 cgroup 版本。现在默认配置了 cgroup v2。
- CRI-O
- 充当实施安全界限和管理容器工作负载的轻量级容器运行时。
17.4.2.2. 命令行主机访问
必须限制直接访问主机,以避免修改主机或访问不应访问的 pod。对于需要直接访问主机的用户,建议使用外部验证器(如 SSSD 和 LDAP)来管理访问权限。这有助于通过 Machine Config Operator 在集群间保持一致。
不要配置对任何 OpenShift Container Platform 集群服务器上的 root ID 的直接访问。
您可以使用以下方法连接到集群中的节点:
- 使用 debug pod
这是推荐的访问节点的方法。要调试或连接到节点,请运行以下命令:
$ oc debug node/<worker_node_name>
连接到节点后,运行以下命令访问根文件系统:
# chroot /host
这可让您在节点上的 debug pod 中 root 访问权限。如需更多信息,请参阅"启动具有 root 访问权限的 debug pod"。
- 直接 SSH
避免使用 root 用户。反之,使用核心用户 ID (或您自己的 ID)。要使用 SSH 连接到节点,请运行以下命令:
$ ssh core@<worker_node_name>
重要最初,核心用户 ID 被授予集群中的
sudo
权限。如果无法使用 SSH 连接到节点,请参阅 如何使用 SSH 堡垒 pod 连接到 OpenShift Container Platform 4.x 集群节点,将 SSH 密钥添加到 core 用户。
使用 SSH 连接到节点后,运行以下命令访问 root shell:
$ sudo -i
- 控制台访问
确保控制台安全。不允许使用 root ID 直接登录,而是使用单独的 ID。
注意按照您的组织的最佳实践保护控制台访问。
17.4.2.3. Linux 功能
Linux 功能定义进程可以在主机系统上执行的操作。默认情况下,除非应用了安全措施,否则 pod 会被授予多个功能。这些默认功能如下:
-
CHOWN
-
DAC_OVERRIDE
-
FSETID
-
FOWNER
-
SETGID
-
SETUID
-
SETPCAP
-
NET_BIND_SERVICE
-
KILL
您可以通过配置安全性上下文约束(SCC)来修改 Pod 可接收哪些功能。
您不能为 pod 分配以下功能:
-
SYS_ADMIN
:授予升级权限的强大功能。允许此功能可能会破坏安全界限并造成重大安全风险。 -
NET_ADMIN
:允许控制网络,如 SR-IOV 端口,但可以使用现代设置中的替代解决方案替代。
有关 Linux 功能的更多信息,请参阅 Linux capabilities man page。
17.4.3. 安全性上下文约束
与 RBAC 资源控制用户访问的方式类似,管理员可以使用安全性上下文约束 (SCC) 来控制 Pod 的权限。这些权限决定了 Pod 可以执行的操作以及它们可以访问的资源。您可以使用 SCC 定义 Pod 必须运行的一组条件。
通过安全性上下文约束,管理员可以控制以下安全限制:
-
pod 是否可以使用
allowPrivilegedContainer
标志运行特权容器 -
使用
allowPrivilegeEscalation
标记限制 pod - 容器可以请求的功能
- 将主机目录用作卷
- 容器的 SELinux 上下文
- 容器用户 ID
- 使用主机命名空间和网络
-
拥有 pod 卷的
FSGroup
的分配 - 允许的补充组的配置
- 容器是否需要对其 root 文件系统进行写访问权限
- 卷类型的使用
-
允许的
seccomp
配置集的配置
安装期间会创建默认 SCC,安装一些 Operator 或其他组件。作为集群管理员,您还可以使用 OpenShift CLI (oc
) 创建自己的 SCC。
有关默认安全性上下文约束的详情,请参考 默认安全性上下文约束。
不要修改默认 SCC。自定义默认 SCC 可能会导致在一些平台 Pod 部署或 OpenShift Container Platform 升级时出现问题。另外,默认 SCC 值会在一些集群升级过程中重置为默认值,这会丢弃对这些 SCC 的所有自定义。
根据需要创建并修改您自己的 SCC,而不是修改默认 SCC。有关详细步骤,请参阅 创建安全性上下文约束。
您可以使用以下基本 SCC:
-
restricted
-
restricted-v2
restricted-v2
SCC 是新安装提供的最严格的 SCC,默认用于经过身份验证的用户。它与 Pod Security Admission (PSA)限制一致并提高安全性,因为原始 restricted
SCC 的限制较低。它还有助于在多个发行版本间从原始 SCC 转换到 v2。最后,原始 SCC 已被弃用。因此,建议使用 restricted-v2
SCC。
您可以运行以下命令来检查 restricted-v2
SCC:
$ oc describe scc restricted-v2
输出示例
Name: restricted-v2 Priority: <none> Access: Users: <none> Groups: <none> Settings: Allow Privileged: false Allow Privilege Escalation: false Default Add Capabilities: <none> Required Drop Capabilities: ALL Allowed Capabilities: NET_BIND_SERVICE Allowed Seccomp Profiles: runtime/default Allowed Volume Types: configMap,downwardAPI,emptyDir,ephemeral,persistentVolumeClaim,projected,secret Allowed Flexvolumes: <all> Allowed Unsafe Sysctls: <none> Forbidden Sysctls: <none> Allow Host Network: false Allow Host Ports: false Allow Host PID: false Allow Host IPC: false Read Only Root Filesystem: false Run As User Strategy: MustRunAsRange UID: <none> UID Range Min: <none> UID Range Max: <none> SELinux Context Strategy: MustRunAs User: <none> Role: <none> Type: <none> Level: <none> FSGroup Strategy: MustRunAs Ranges: <none> Supplemental Groups Strategy: RunAsAny Ranges: <none>
restricted-v2
SCC 明确拒绝除显式允许之外的所有内容。以下设置定义允许的功能和安全限制:
-
默认添加能力:设置为 <
none>
。这意味着默认不会向 pod 添加任何功能。 -
所需的丢弃能力:设置为
ALL
。这会丢弃 pod 的所有默认 Linux 功能。 -
允许的功能:
NET_BIND_SERVICE
。pod 可以请求此功能,但默认情况下不添加它。 -
允许的
seccomp
配置集:runtime/default
。
如需更多信息,请参阅管理安全性上下文约束。