容器将一个应用程序及其所有依赖项打包成单一镜像，可在不发生改变的情况下从开发环境提升到测试环境，再提升到生产环境。容器可能是大型应用程序的一部分，与其他容器紧密合作。

容器提供不同环境间的一致性和多个部署目标：物理服务器、虚拟机 (VM) 和私有或公有云。

使用容器的一些好处包括：

请参阅红帽客户门户中的了解 Linux 容器以查找更多有关 Linux 容器的信息。如需了解有关 RHEL 容器工具的信息，请参阅 RHEL 产品文档中的构建、运行和管理容器。

OpenShift Container Platform 等平台的任务是自动化部署、运行和管理容器化应用程序。作为核心功能，OpenShift Container Platform 依赖于 Kubernetes 项目来提供在可扩展数据中心跨许多节点编配容器的引擎。

Kubernetes 是一个项目，可使用不同的操作系统和附加组件来运行，它们不提供项目的支持性保证。因此，不同 Kubernetes 平台的安全性可能会有所不同。

OpenShift Container Platform 旨在锁定 Kubernetes 安全性，并将平台与各种扩展组件集成。为实现这一目标，OpenShift Container Platform 利用了广泛的红帽开源技术生态系统，包括操作系统、身份验证、存储、网络、开发工具、基础容器镜像和其他许多组件。

OpenShift Container Platform 可以利用红帽的经验，发现平台本身以及在平台上运行的容器化应用程序中存在的漏洞并快速部署修复程序。红帽的经验还涉及到在新组件可用后高效地将它们与 OpenShift Container Platform 集成，以及根据各个客户的需求对技术进行调整。

容器简化了将许多应用程序部署在同一主机上运行的操作，每个容器启动都使用相同的内核和容器运行时。应用程序可以归很多用户所有，并且由于是保持独立的，他们可以毫无问题地同时运行这些应用程序的不同版本甚至不兼容的版本。

在 Linux 中，容器只是一种特殊的进程，因此在很多方面，保护容器与保护任何其他运行的进程类似。运行容器的环境始于操作系统，它可以保护主机内核不受容器和主机上运行的其他进程的影响，同时还可以保护容器不受彼此的影响。

由于 OpenShift Container Platform 4.4 在 RHCOS 主机上运行，同时可选择使用 Red Hat Enterprise Linux (RHEL) 作为 worker 节点，因此以下概念将默认应用于任何已部署的 OpenShift Container Platform 集群。这些 RHEL 安全功能是确保以更加安全的方式在 OpenShift 中运行容器的核心所在：

RHCOS 是 Red Hat Enterprise Linux (RHEL) 的一个版本，它经过特别配置，可用作 OpenShift Container Platform 集群上的 control plane (master) 和 worker 节点。因此，RHCOS 适用于高效运行容器工作负载，以及 Kubernetes 和 OpenShift 服务。

为了进一步保护 OpenShift Container Platform 集群中的 RHCOS 系统，大多数容器（除了管理或监控主机系统本身的容器外）都应以非 root 用户身份运行。要保护您自己的 OpenShift Container Platform 集群，推荐的最佳实践是降低权限级别或创建包含最少权限的容器。

传统虚拟化提供了另一种在相同物理主机上将应用程序环境保持独立的方法。但是，虚拟机的工作方式与容器不同。虚拟化依赖于虚拟机监控程序启动虚拟客户机 (VM)，每个虚拟机都有自己的操作系统 (OS)，具体表现为运行的内核、正在运行的应用程序及其依赖项。

使用 VM，虚拟机监控程序会将虚拟客户机相互隔离并与主机内核隔离。这样可减少可访问虚拟机监控程序的个人和进程，进而缩小物理服务器上的攻击面。尽管如此，仍然必须对安全性进行监控：一个虚拟客户机可能利用虚拟机监控程序的错误来获取对另一个虚拟机或主机内核的访问权限。当需要修补操作系统时，必须对所有使用该操作系统的虚拟客户机进行修补。

容器可在虚拟客户机中运行，这种方式在有些用例中可能是可取的。例如，您可能在容器中部署传统应用程序，以便将某个应用程序转移到云端。

但是，在单一主机上进行容器分离提供了一种更加轻便、灵活且易于部署的解决方案。这种部署模型特别适合云原生应用程序。容器通常比 VM 小得多，消耗的内存和 CPU 也更少。

请参阅 RHEL 7 容器文档中的 Linux 容器与 KVM 虚拟化的比较，以了解容器和虚拟机之间的差别。

在部署 OpenShift Container Platform 时，您可以选择安装程序置备的基础架构（有多个可用的平台）或您自己的用户置备的基础架构。用户置备的基础架构可能有益于一些低级别的安全相关配置，如启用 FIPS 合规性或在第一次引导时添加内核模块。同样，用户置备的基础架构适合用于断开连接的 OpenShift Container Platform 部署。

请记住，在为 OpenShift Container Platform 进行安全增强和其他配置更改方面，应包括以下目标：

为实现这些目标，应该在安装过程中使用 Machine Config Operator 应用到各组节点的 MachineConfig，通过 Ignition 或更高版本进行大多数节点更改。您可以通过这种方式进行的与安全性相关的配置更改示例包括：

除了 Machine Config Operator 外，还有一些其他的 Operator 可用来配置由 Cluster Version Operator (CVO) 管理的 OpenShift Container Platform 基础架构。CVO 可以为 OpenShift Container Platform 集群更新的很多方面实现自动化。

RHEL 8 安全强化指南介绍了如何处理任何 RHEL 系统的安全问题。

使用本指南来学习如何处理加密、评估漏洞以及评估不同服务受到的威胁。同样，您可以了解如何扫描合规标准、检查文件完整性、执行审核以及对存储设备进行加密。

了解了您要强化的功能后，您可以决定如何在 RHCOS 中强化它们。

不建议在 OpenShift Container Platform 中直接修改 RHCOS 系统。取而代之，您应该考虑在节点池中修改系统，如 worker 节点和 master 节点。在非裸机安装中，当需要一个新节点时，您可以请求一个您所需的类型的新节点，并且它将从 RHCOS 镜像创建，再加上之前创建的修改。

在安装前、在安装过程中以及集群启动和运行后，您有机会修改 RHCOS。

FIPS 合规性是高安全性环境中所需的最重要的组件之一，可确保节点上只允许使用支持的加密技术。要了解红帽对 OpenShift Container Platform 合规框架的观点，请参阅 OpenShift 安全性指南手册中的“风险管理和法规就绪状态”一章。

应用程序和基础架构由随时可用的组件组成，许多组件都是开源软件包，如 Linux 操作系统、JBoss Web Server、PostgreSQL 和 Node.js。

这些软件包也有容器化版本可用。然而，您需要知道软件包最初来自哪里，使用什么版本，是谁构建的，以及软件包内是否有恶意代码。

需要回答的一些问题包括：

通过从红帽通用基础镜像 (UBI) 构建容器，您可以保证您的容器镜像基础由 Red Hat Enterprise Linux 中包含的同一 RPM 打包软件组成。使用或重新分发 UBI 镜像不需要订阅。

为确保容器本身持续安全，安全扫描功能（直接从 RHEL 使用或添加到 OpenShift Container Platform）可在您使用的镜像有漏洞时发出警告。RHEL 中提供了 OpenSCAP 镜像扫描，并且可添加 Container Security Operator 来检查 OpenShift Container Platform 中使用的容器镜像。

要创建容器化应用程序，您通常以可信基础镜像开始，该镜像提供的组件通常由操作系统提供。这些组件包括库、实用程序以及应用程序在操作系统文件系统中应该看到的其他功能。

创建红帽通用基础镜像 (UBI) 是为了鼓励任何人在构建其自己的容器时都先使用一个完全由 Red Hat Enterprise Linux rpm 软件包及其他内容组成的容器镜像。这些 UBI 镜像会定期更新，以应用最新的安全补丁，并可自由地与构建用来包含您自己的软件的容器镜像一起使用和重新分发。

搜索红帽生态系统目录，以便查找和检查不同 UBI 镜像的健康状态。作为创建安全容器镜像的人员，您可能对两种通用 UBI 镜像类型感兴趣：

请记住，虽然 UBI 镜像可自由使用且可重新发布，但红帽对这些镜像的支持只能通过 Red Hat 产品订阅获得。

请参阅 Red Hat Enterprise Linux 文档中 的使用红帽通用基础镜像来获得有关如何使用标准、最小和 init UBI 镜像作为构建基础的信息。

对于 Red Hat Enterprise Linux (RHEL) 系统，可从 openscap-utils 软件包中获得 OpenSCAP 扫描功能。在 RHEL 中，您可以使用 openscap-podman 命令扫描针镜像中的漏洞。请参阅 Red Hat Enterprise Linux 文档中的扫描容器和容器镜像中的漏洞。

OpenShift Container Platform 可让您在 CI/CD 过程中利用 RHEL 扫描程序。例如，您可以集成静态代码分析工具来测试源代码中的安全漏洞，并集成软件组成分析工具来标识开源库，以提供关于这些库的元数据，如已知漏洞。

OpenShift Container Platform 使用对象注解来扩展功能。外部工具（如漏洞扫描程序）可以使用元数据为镜像对象添加注解，以汇总结果和控制 Pod 执行。本节描述了该注解的公认格式，以便在控制台中可靠使用它来为用户显示有用的数据。

quality.images.openshift.io/<qualityType>.<providerId>: {}

quality.images.openshift.io/vulnerability.blackduck: {}
quality.images.openshift.io/vulnerability.jfrog: {}
quality.images.openshift.io/license.blackduck: {}
quality.images.openshift.io/vulnerability.openscap: {}

{
  "name": "OpenSCAP",
  "description": "OpenSCAP vulnerability score",
  "timestamp": "2016-09-08T05:04:46Z",
  "reference": "https://www.open-scap.org/930492",
  "compliant": true,
  "scannerVersion": "1.2",
  "summary": [
    { "label": "critical", "data": "4", "severityIndex": 3, "reference": null },
    { "label": "important", "data": "12", "severityIndex": 2, "reference": null },
    { "label": "moderate", "data": "8", "severityIndex": 1, "reference": null },
    { "label": "low", "data": "26", "severityIndex": 0, "reference": null }
  ]
}

{
  "name": "Red Hat Container Catalog",
  "description": "Container health index",
  "timestamp": "2016-09-08T05:04:46Z",
  "reference": "https://access.redhat.com/errata/RHBA-2016:1566",
  "compliant": null,
  "scannerVersion": "1.2",
  "summary": [
    { "label": "Health index", "data": "B", "severityIndex": 1, "reference": null }
  ]
}

$ oc annotate image <image> \
    quality.images.openshift.io/vulnerability.redhatcatalog='{ \
    "name": "Red Hat Container Catalog", \
    "description": "Container health index", \
    "timestamp": "2020-06-01T05:04:46Z", \
    "compliant": null, \
    "scannerVersion": "1.2", \
    "reference": "https://access.redhat.com/errata/RHBA-2020:2347", \
    "summary": "[ \
      { "label": "Health index", "data": "B", "severityIndex": 1, "reference": null } ]" }'

annotations:
  images.openshift.io/deny-execution: true

$ curl -X PATCH \
  -H "Authorization: Bearer <token>" \
  -H "Content-Type: application/merge-patch+json" \
  https://<openshift_server>:8443/oapi/v1/images/<image_id> \
  --data '{ <image_annotation> }'

{
"metadata": {
  "annotations": {
    "quality.images.openshift.io/vulnerability.redhatcatalog":
       "{ 'name': 'Red Hat Container Catalog', 'description': 'Container health index', 'timestamp': '2020-06-01T05:04:46Z', 'compliant': null, 'reference': 'https://access.redhat.com/errata/RHBA-2020:2347', 'summary': [{'label': 'Health index', 'data': '4', 'severityIndex': 1, 'reference': null}] }"
    }
  }
}

您可以使用一些工具来扫描和跟踪您下载和部署的容器镜像的内容。但是，容器镜像有很多公共来源。在使用公共容器 registry 时，您可以使用可信源添加一层保护。

在管理不可变容器时，消耗安全更新尤其重要。不可变容器是在运行时永远不会更改的容器。当您部署不可变容器时，您不会介入正在运行的容器来替换一个或多个二进制文件。从操作角度来说，您可以重建并重新部署更新的容器镜像以替换某个容器，而不是更改该容器。

红帽的已认证镜像：

已知漏洞列表不断扩展，因此您必须一直跟踪部署的容器镜像的内容以及新下载的镜像。您可以使用红帽安全公告 (RHSA) 来提醒您红帽的已认证容器镜像中出现的任何新问题，并指引您找到更新的镜像。另外，您还可以访问红帽生态系统目录查找每个红帽镜像的各种安全相关问题。

红帽在红帽生态系统目录的容器镜像部分列出了适用于红帽产品和合作伙伴产品的已认证容器镜像。在该目录中，您可以查看每个镜像的详情，包括 CVE、软件包列表和健康状态分数。

红帽镜像实际存储在所谓的 红帽 Registry 中，其具体代表为公共容器 registry (registry.access.redhat.com) 和经过身份验证的 registry (registry.redhat.io)。这两者基本包括同一组容器镜像，其中 registry.redhat.io 包括了一些需要使用红帽订阅凭证进行身份验证的额外镜像。

红帽会监控容器内容以了解漏洞，并定期进行更新。当红帽发布安全更新（如 glibc、DROWN 或 Dirty Cow 的修复程序）时，任何受影响的容器镜像也会被重建并推送到 Red Hat Registry。

红帽使用 health index 来反映通过红帽生态系统目录提供的每个容器的安全风险。由于容器消耗红帽提供的软件和勘误表流程，旧的、过时的容器不安全，而全新容器则更安全。

为了说明容器的年龄，红帽容器目录使用一个等级系统。新鲜度等级是一个镜像可用的最旧、最严重的安全公告衡量标准。“A”比“F”状态更新。如需了解这个等级系统的更多详情，请参阅 Red Hat Container Catalog 内部使用的容器健康状态索引等级。

如需详细了解与红帽软件相关的安全更新和漏洞，请参阅红帽产品安全中心。查看红帽安全公告以搜索具体公告和 CVE。

OpenShift Container Platform 包括 OpenShift Container Registry，它是作为平台集成组件运行的私有 registry，可用于管理容器镜像。OpenShift Container Registry 提供基于角色的访问控制，供您管理谁可以拉取和推送哪些容器镜像。

OpenShift Container Platform 还支持与其他您可能已经使用的私有 registry 集成，如 Red Hat Quay。

Red Hat Quay 是红帽的一个企业级容器 registry 产品。Red Hat Quay 的开发是通过上游 Project Quay 完成的。Red Hat Quay 可用于在内部部署，或通过 Red Hat Quay 在 Quay.io 的托管版本部署。

与安全性相关的 Red Hat Quay 功能包括：

Red Hat Quay 不断与 OpenShift Container Platform 持续集成，包含几个特别值得关注的 OpenShift Container Platform Operator。Quay Bridge Operator 可让您将 OpenShift Container Platform 内部 registry 替换为 Red Hat Quay。Quay Container Security Operator 可让您检查在 OpenShift Container Platform 中运行并从 Red Hat Quay registry 拉取的镜像的漏洞。

使用 OpenShift Container Platform 作为容器构建的标准平台可保证构建环境的安全。遵循“一次构建，随处部署”的原则可确保构建过程的产品就是在生产环境中部署的产品。

保持容器的不可变性也是很重要的。您不应该修补运行中的容器，而应该重建并重新部署这些容器。

随着您的软件逐步进入构建、测试和生产阶段，组成软件供给链的工具必须是可信的。下图演示了可整合到容器化软件的可信软件供应链中的流程和工具：

OpenShift Container Platform 可以与可信代码存储库（如 GitHub）和开发平台（如 Che）集成，用于创建和管理安全代码。单元测试可以依赖 Cucumber 和 JUnit。您可以通过 Anchore 或 Twistlock 检查容器中的漏洞和合规问题，并使用镜像扫描工具，如 AtomicScan 或 Clair。Sysdig 等工具可以提供对容器化应用程序的持续监控。

您可以使用 Source-to-Image (S2I) 将源代码和基础镜像组合起来。构建器镜像利用 S2I 使您的开发和运维团队能够就可重复生成的构建环境展开合作。对于可作为通用基础镜像 (UBI) 镜像的 Red Hat S2I 镜像，您现在可以使用从真实 RHEL RPM 软件包构建的基础镜像自由重新分发您的软件。红帽取消了订阅限制以允许这一操作。

当开发人员使用构建镜像通过 Git 提交某个应用程序的代码时，OpenShift Container Platform 可以执行以下功能：

您可以使用集成的 OpenShift Container Registry 来管理对最终镜像的访问。S2I 和原生构建镜像会自动推送到 OpenShift Container Registry。

除了包含的用于 CI 的 Jenkins 外，您还可以使用 RESTful API 将您自己的构建和 CI 环境与 OpenShift Container Platform 集成，并使用与 API 兼容的镜像 registry。

在某些情况下，构建操作需要凭证才能访问依赖的资源，但这些凭证最好不要在通过构建生成的最终应用程序镜像中可用。您可以定义输入 secret 以实现这一目的。

例如，在构建 Node.js 应用程序时，您可以为 Node.js 模块设置私有镜像。要从该私有镜像下载模块，您必须为包含 URL、用户名和密码的构建提供自定义的 .npmrc 文件。为安全起见，不应在应用程序镜像中公开您的凭证。

通过使用此示例场景，您可以在新 BuildConfig 对象中添加输入 secret：

您可以对容器镜像管理和构建过程进行设计以使用容器层，以便您可以分开控制。

例如，一个运维团队负责管理基础镜像，而架构师则负责管理中间件、运行时、数据库和其他解决方案。然后开发人员可以专注于应用程序层并专注于编写代码。

由于每天都会识别出新的漏洞，因此您需要一直主动检查容器内容。要做到这一点，您应该将自动安全测试集成到构建或 CI 过程中。例如：

您的 CI 过程应该包含相应的策略，为构建标记出通过安全扫描发现的问题，以便您的团队能够采取适当行动来解决这些问题。您应该为自定义构建容器签名，以确保在构建和部署之间不会修改任何内容。

利用 GitOps 方法，您不仅可以使用相同的 CI/CD 机制来管理应用程序配置，还可以管理 OpenShift Container Platform 基础架构。

借助 Kubernetes 和 Kourier，您可以在 OpenShift Container Platform 中使用 Knative 来构建、部署和管理无服务器应用程序。和其他构建一样，您可以使用 S2I 镜像来构建容器，然后使用 Knative 服务提供它们。通过 OpenShift Container Platform Web 控制台的 Topology 视图 查看 Knative 应用程序构建。

如果在构建过程中发生某种情况，或者部署了镜像后发现一个漏洞，您可以使用基于策略的自动化部署工具进行修复。您可以使用触发器来重建和替换镜像，确保不可变的容器进程，而不是修补正在运行的容器，这种做法是不推荐的。

例如，您使用三个容器镜像层构建了一个应用程序：核心、中间件和应用程序。由于在核心镜像中发现了一个问题，该镜像被重建。构建完成后，该镜像被推送到 OpenShift Container Registry。OpenShift Container Platform 检测到镜像已更改，并根据定义的触发器自动重建并部署应用程序镜像。这一更改包含了固定的库，并确保产品代码与最新镜像是一致的。

您可以使用 oc set triggers 命令来设置部署触发器。例如，要为名为 deployment-example 的部署设置触发器：

$ oc set triggers deploy/deployment-example \
    --from-image=example:latest \
    --containers=web

务必要确保实际部署了所需的镜像，还要确保包括容器内容的镜像来自可信源，且尚未更改。加密签名提供了这一保证。OpenShift Container Platform 可让集群管理员应用广泛或狭窄的安全策略，以反应部署环境和安全要求。该策略由两个参数定义：

您可以使用这些策略参数来允许、拒绝整个 registry、部分 registry 或单独的镜像，或者要求具有信任关系。使用可信公钥，您可以确保以加密的方式验证源。该策略规则应用于节点。策略可以在所有节点中统一应用，或针对不同的节点工作负载（例如：构建、区域或环境）加以应用。

{
    "default": [{"type": "reject"}],
    "transports": {
        "docker": {
            "access.redhat.com": [
                {
                    "type": "signedBy",
                    "keyType": "GPGKeys",
                    "keyPath": "/etc/pki/rpm-gpg/RPM-GPG-KEY-redhat-release"
                }
            ]
        },
        "atomic": {
            "172.30.1.1:5000/openshift": [
                {
                    "type": "signedBy",
                    "keyType": "GPGKeys",
                    "keyPath": "/etc/pki/rpm-gpg/RPM-GPG-KEY-redhat-release"
                }
            ],
            "172.30.1.1:5000/production": [
                {
                    "type": "signedBy",
                    "keyType": "GPGKeys",
                    "keyPath": "/etc/pki/example.com/pubkey"
                }
            ],
            "172.30.1.1:5000": [{"type": "reject"}]
        }
    }
}

该策略可以在节点上保存为 /etc/containers/policy.json。最好使用新的 MachineConfig 对象将此文件保存到节点。这个示例强制执行以下规则：

签名传输是一种存储和检索二进制签名 blob 的方法。签名传输有两种类型。

OpenShift Container Platform API 负责管理使用 atomic 传输类型的签名。您必须将使用此签名类型的镜像存储在 OpenShift Container Registry 中。由于 docker/distribution extensions API 会自动发现镜像签名端点，因此不需要额外的配置。

使用 docker 传输类型的签名由本地文件或者 Web 服务器提供。这些签名更为灵活，您可以提供来自任何容器镜像 registry 的镜像，并使用独立的服务器来提供二进制签名。

但是，docker 传输类型需要进行额外的配置。您必须为节点配置签名服务器的 URI，方法是将随机命名的 YAML 文件放在主机系统上的目录中，默认为 /etc/containers/registries.d。YAML 配置文件包含 registry URI 和签名服务器 URI，或 sigstore：

docker:
    access.redhat.com:
        sigstore: https://access.redhat.com/webassets/docker/content/sigstore

在这个示例中，Red Hat Registry access.redhat.com 是为 docker 传输类型提供签名的签名服务器。其 URI 在 sigstore 参数中定义。您可以将此文件命名为 /etc/containers/registries.d/redhat.com.yaml，并使用 Machine Config Operator 自动将文件放在集群中的每个节点上。由于策略和 registry.d 文件由容器运行时动态加载，因此不需要重启服务。

Secret 对象类型提供了一种机制来保存敏感信息，如密码、OpenShift Container Platform 客户端配置文件、dockercfg 文件和私有源存储库凭证。Secret 将敏感内容与 Pod 分离。您可以使用卷插件将 secret 信息挂载到容器中，系统也可以使用 secret 代表 Pod 执行操作。

例如，要在部署配置中添加 secret，以便它可以访问私有镜像存储库，请执行以下操作：

配置映射与 secret 类似，但设计为能支持与不含敏感信息的字符串配合使用。ConfigMap 对象包含配置数据的键值对，这些数据可在 Pod 中消耗或用于存储控制器等系统组件的配置数据。

您可以将自己的持续部署 (CD) 工具与 OpenShift Container Platform 集成。

利用 CI/CD 和 OpenShift Container Platform，您可以自动执行重建应用程序的过程，以纳入最新的修复、测试，并确保它在环境中随处部署。

多租户允许 OpenShift Container Platform 集群上由多个用户拥有并在多个主机和命名空间中运行的应用程序保持相互隔离并与外部攻击隔离。要获取多租户，您可以将基于角色的访问控制 (RBAC) 应用到 Kubernetes 命名空间。

在 Kubernetes 中，命名空间是应用程序可以独立于其他应用程序运行的区域。OpenShift Container Platform 使用和扩展命名空间的方式是添加额外的注解，包括在 SELinux 中的 MCS 标签，并将这些扩展命名空间标识为项目。在项目范围内，用户可以维护自己的集群资源，包括服务帐户、策略、限制和各种其他对象。

可将 RBAC 对象分配给项目，以便授权所选用户访问这些项目。该授权采用规则、角色和绑定的形式：

本地 RBAC 角色和绑定将用户或组附加到特定项目。集群 RBAC 可将集群范围的角色和绑定附加到集群中的所有项目。有默认的集群角色可以分配，用来提供 admin、basic-user、cluster-admin 和 cluster-status 访问。

RBAC 可控制用户和组与可用项目之间的访问规则，而准入插件可定义对 OpenShift Container Platform 主 API 的访问。准入插件形成一个由以下部分组成的规则链：

API 请求经过一个链中的准入插件，沿途的任何失败都会导致请求遭到拒绝。每个准入插件都与特定资源关联，且只响应这些资源的请求。

OpenShift Container Platform 的框架中有多个组件，它们使用基于 REST 的 HTTPS 通信，通过 TLS 证书利用加密功能。OpenShift Container Platform 的安装程序会在安装过程中配置这些证书。生成此流量的一些主要组件如下：

OpenShift Container Platform 使用软件定义网络 (SDN) 来提供一个统一的集群网络，它允许集群中的不同容器相互间进行通信。

默认情况下，网络策略模式使项目中的所有 Pod 都可被其他 Pod 和网络端点访问。要在一个项目中隔离一个或多个 Pod，您可以在该项目中创建 NetworkPolicy 对象来指示允许的入站连接。使用多租户模式，您可以为 Pod 和服务提供项目级别的隔离。

使用网络策略，您可以在同一项目中将 Pod 相互隔离。网络策略可以拒绝对 Pod 的所有网络访问，只允许入口控制器的连接，拒绝其他项目中的 Pod 的连接，或为网络的行为方式设置类似的规则。

默认情况下，每个运行中的容器只有一个网络接口。Multus CNI 插件可让您创建多个 CNI 网络，然后将任何这些网络附加到您的 Pod。这样，您可以执行一些操作，例如将私有数据单独放在更为受限的网络上，并在每个节点上使用多个网络接口。

OpenShift Container Platform 允许您为单个集群上的网络流量分段以创建多租户集群，使用户、团队、应用程序和环境与非全局资源隔离。

如何配置从 OpenShift Container Platform 集群外对 Kubernetes 服务的访问会产生很多安全影响。除了公开 HTTP 和 HTTPS 路由外，入口路由还允许您设置 NodePort 或 LoadBalancer 入口类型。NodePort 从每个集群 worker 中公开应用程序的服务 API 对象。借助 LoadBalancer，您可以将外部负载均衡器分配给 OpenShift Container Platform 集群中关联的服务 API 对象。

OpenShift Container Platform 提供了使用路由器或防火墙方法控制出口流量的功能。例如，您可以使用 IP 白名单来控制对数据库的访问。集群管理员可以为 OpenShift Container Platform SDN 网络供应商中的项目分配一个或多个出口 IP 地址。同样，集群管理员可以使用出口防火墙防止出口流量传到 OpenShift Container Platform 集群之外。

通过分配固定出口 IP 地址，您可以将特定项目的所有出站流量分配到该 IP 地址。使用出口防火墙时，您可以防止 Pod 连接到外部网络，防止 Pod 连接到内部网络，或限制 Pod 对特定内部子网的访问。

容器对于无状态和有状态的应用程序都很有用。保护附加存储是保护有状态服务的一个关键元素。通过使用 Container Storage Interface (CSI)，OpenShift Container Platform 可以包含支持 CSI 接口的任何存储后端中的存储。

OpenShift Container Platform 为多种存储提供插件，包括：

具有动态置备的存储类型的插件标记为星号 (*)。对于相互通信的所有 OpenShift Container Platform 组件，传输中的数据都通过 HTTPS 来加密。

您可以以任何方式在主机上挂载持久性卷（PV）。不同的存储类型具有不同的功能，每个 PV 的访问模式可以被设置为特定卷支持的特定模式。

例如：NFS 可以支持多个读/写客户端，但一个特定的 NFS PV 可能会以只读方式导出。每个 PV 都有自己的一组访问模式来描述特定 PV 的功能，如 ReadWriteOnce、ReadOnlyMany 和 ReadWriteMany。

对于 NFS 等共享存储供应商，PV 将其组 ID (GID) 注册为 PV 资源上的注解。然后，当 Pod 声明 PV 时，注解的 GID 会添加到 Pod 的补充组中，为该 pod 授予共享存储内容的访问权限。

对于 AWS Elastic Block Store (EBS)、GCE Persistent Disk 和 iSCSI 等块存储供应商，OpenShift Container Platform 使用 SELinux 功能为非特权 Pod 保护挂载卷的根目录，从而使所挂载的卷由与其关联的容器所有并只对该容器可见。

建议集群管理员熟悉 Event 资源类型，并查看系统事件列表以确定值得关注的事件。事件与命名空间关联，可以是与它们相关的资源的命名空间，对于集群事件，也可以是 default 命名空间。default 命名空间包含与监控或审核集群相关的事件，如节点事件和与基础架构组件相关的资源事件。

Master API 和 oc 命令不通过提供参数来将事件列表的范围限定为与节点相关的事件。一个简单的方法是使用 grep：

$ oc get event -n default | grep Node
1h         20h         3         origin-node-1.example.local   Node      Normal    NodeHasDiskPressure   ...

更灵活的方法是以其他工具可以处理的形式输出事件。例如，以下示例针对 JSON 输出使用 jq 工具以仅提取 NodeHasDiskPressure 事件：

$ oc get events -n default -o json \
  | jq '.items[] | select(.involvedObject.kind == "Node" and .reason == "NodeHasDiskPressure")'
{
  "apiVersion": "v1",
  "count": 3,
  "involvedObject": {
    "kind": "Node",
    "name": "origin-node-1.example.local",
    "uid": "origin-node-1.example.local"
  },
  "kind": "Event",
  "reason": "NodeHasDiskPressure",
  ...
}

与资源创建、修改或删除相关的事件也很适合用来检测到集群误用情况。例如，以下查询可以用来查找过度拉取镜像：

$ oc get events --all-namespaces -o json \
  | jq '[.items[] | select(.involvedObject.kind == "Pod" and .reason == "Pulling")] | length'
4

使用 oc log 命令，您可以实时查看容器日志、构建配置和部署。不同的用户可对日志具有不同的访问权限：

要保存日志以供进一步审核和分析，您可以启用 cluster-logging 附加功能来收集、管理和查看系统、容器和审计日志。您可以通过 Elasticsearch Operator 和 Cluster Logging Operator 部署、管理和升级集群日志记录。

使用审计日志，您可以跟踪与用户、管理员或其他 OpenShift Container Platform 组件的行为方式相关的一系列活动。API 审计日志记录在每个服务器上完成。

默认情况下，OpenShift Container Platform 使用 Ingress Operator 创建内部 CA 并发布对 .apps 子域下应用程序有效的通配符证书。web 控制台和 CLI 也使用此证书。

内部基础架构 CA 证书是自签名的。虽然这种流程被某些安全或 PKI 团队认为是不当做法，但这里的风险非常小。隐式信任这些证书的客户端仅是集群中的其他组件。将默认通配符证书替换为由 CA bundle 中已包括的公共 CA 发布的证书，该证书由容器用户空间提供，允许外部客户端安全地连接到 .apps 子域下运行的应用程序。

您可以替换 .apps 子域下所有应用程序的默认入口证书。替换了证书后，包括 web 控制台和 CLI 在内的所有应用程序都会具有指定证书提供的加密。

默认 API 服务器证书由内部 OpenShift Container Platform 集群 CA 发布。您可以添加一个或多个 API 服务器将根据客户端请求的完全限定域名（FQDN）返回的证书，例如使用反向代理或负载均衡器时。

服务用证书旨在为需要加密的复杂中间件应用程序提供支持。这些证书是作为 TLS web 服务器证书发布的。

service-ca 控制器使用 x509.SHA256WithRSA 签名算法来生成服务证书。

生成的证书和密钥采用 PEM 格式，分别存储在所创建 secret 的 tls.crt 和 tls.key 中。证书和密钥在接近到期时自动替换。

用于发布服务证书的服务 CA 证书在 26 个月内有效，并在有效期少于 6 个月时进行自动轮转。轮转后，以前的服务 CA 配置仍会被信任直到其过期为止。这将为所有受影响的服务建立一个宽限期，以在过期前刷新其密钥内容。如果没有在这个宽限期内对集群进行升级（升级会重启服务并刷新其密钥），您可能需要手动重启服务以避免在上一个服务 CA 过期后出现故障。

$ for I in $(oc get ns -o jsonpath='{range .items[*]} {.metadata.name}{"\n"} {end}'); \
      do oc delete pods --all -n $I; \
      sleep 1; \
      done

要保证与服务的通信的安全，请在与服务相同的命名空间中将签名的服务证书和密钥对生成 secret。

Pod 可通过挂载使用 service.beta.openshift.io/inject-cabundle=true 注解的 ConfigMap 对象来访问服务 CA 证书。注解后，集群会自动将服务 CA 证书注入配置映射上的 service-ca.crt 键。访问此 CA 证书可允许 TLS 客户端使用服务用证书验证服务连接。

您可以使用 service.beta.openshift.io/inject-cabundle=true 注解 APIService 对象，使其 spec.caBundle 字段由服务 CA 捆绑包填充。这可让 Kubernetes API 服务器验证用于保护目标端点的安全的服务 CA 证书。

您可以使用 service.beta.openshift.io/inject-cabundle=true 注解 CustomResourceDefinition（CRD）对象，使其 spec.conversion.webhook.clientConfig.caBundle 字段 由服务 CA 捆绑包填充。这可让 Kubernetes API 服务器验证用于保护目标端点的安全的服务 CA 证书。

您可以使用 service.beta.openshift.io/inject-cabundle=true 注解 MutatingWebhookConfiguration 对象，使每个 webhook 的 clientConfig.caBundle 字段由服务 CA 捆绑包填充。这可让 Kubernetes API 服务器验证用于保护目标端点的安全的服务 CA 证书。

您可以使用 service.beta.openshift.io/inject-cabundle=true 注解 ValidatingWebhookConfiguration 对象，使每个 webhook 的 clientConfig.caBundle 字段 由服务 CA 捆绑包填充。这可让 Kubernetes API 服务器验证用于保护目标端点的安全的服务 CA 证书。

您可以通过删除关联的 secret 来轮换服务证书。删除 secret 会导致自动创建新 secret，进而生成新的证书。

服务 CA 证书在 26 个月内有效，并在有效期少于 6 个月时进行刷新。

如果需要，您可以按照以下步骤手动刷新服务 CA。

集群以外的客户端通过 api.<cluster_name>.<base_domain> 可访问 API 服务器。您可能希望客户端使用不同主机名访问 API 服务器，无需向客户端发布集群管理的证书颁发机构 (CA) 证书。管理员必须在提供内容时设置 API 服务器使用的自定义默认证书。

用户提供的证书必须在 openshift-config 命名空间中的 kubernetes.io/tls 类型 Secret 中提供。更新 API 服务器集群配置( apiserver/cluster 资源），以启用用户提供的证书。

用户提供的证书由用户管理。

用户提供的证书由用户管理。

根据需要，更新包含用户管理的证书的 secret。

其他资源

通过代理证书，用户可以指定，在平台组件创建出口连接时使用的一个或多个自定义证书颁发机构 (CA) 证书。

Proxy 对象的 trustedCA 字段是对包含用户提供的可信证书颁发机构 (CA) 捆绑包的配置映射的引用。这个捆绑包与 Red Hat Enterprise Linux CoreOS (RHCOS) 信任捆绑包合并，并注入到生成出口 HTTPS 调用的平台组件的信任存储中。例如，image-registry-operator 调用外部镜像 registry 来下载镜像。如果没有指定 trustedCA，则只有 RHCOS 信任的捆绑包用于代理 HTTPS 连接。如果您想要使用自己的证书基础架构，请向 RHCOS 信任捆绑包提供自定义 CA 证书。

trustedCA 字段应当仅由代理验证器使用。验证程序负责从所需的键 ca-bundle.crt 中读取证书捆绑包，并将其复制到 openshift-config-managed 命名空间中名为 trusted-ca-bundle 的配置映射中。被 trustedCA 引用的配置映射的命名空间是 openshift-config：

apiVersion: v1
kind: ConfigMap
metadata:
  name: user-ca-bundle
  namespace: openshift-config
data:
  ca-bundle.crt: |
  -----BEGIN CERTIFICATE-----
  Custom CA certificate bundle.
  -----END CERTIFICATE-----

其他资源

安装程序配置的 additionalTrustBundle 值用于在安装过程中指定任何代理信任的 CA 证书。例如：

$ cat install-config.yaml
. . .
proxy:
  httpProxy: http://<HTTP_PROXY>
  httpsProxy: https://<HTTPS_PROXY>
additionalTrustBundle: |
    -----BEGIN CERTIFICATE-----
   <MY_HTTPS_PROXY_TRUSTED_CA_CERT>
    -----END CERTIFICATE-----
. . .

用户提供的信任捆绑包以配置映射表示。配置映射挂载到进行 HTTPS 调用的平台组件的文件系统中。通常，Operator 会将配置映射挂载到 /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem，但代理并不要求这样做。代理可以修改或检查 HTTPS 连接。在这两种情况下，代理都必须为连接生成新证书并为新证书签名。

完整的代理支持意味着连接到指定的代理服务器并信任它所生成的所有签名。因此，需要让用户指定一个信任的根用户，以便任何连接到该可信根的证书链都被信任。

如果使用 RHCOS 信任捆绑包，请将 CA 证书放在 /etc/pki/ca-trust/source/anchors 中。

详情请参阅 Red Hat Enterprise Linxu 文档的使用共享系统证书。

用户为用户提供的信任捆绑包设定了过期期限。

默认到期条件由 CA 证书本身定义。在 OpenShift Container Platform 或 RHCOS 使用前，由 CA 管理员为证书配置这个证书。

默认情况下，所有使用出口 HTTPS 调用的平台组件将使用 RHCOS 信任捆绑包。如果定义了 trustedCA，它将会被使用。

任何在 RHCOS 节点上运行的服务都可以使用该节点的信任捆绑包。

这些证书由系统而不是用户管理。

更新用户提供的信任捆绑包包括：

将 CA 证书写入 RHCOS 信任捆绑包的机制与将其它文件写入 RHCOS（使用机器配置）完全相同。当 Machine Config Operator (MCO) 应用包含新 CA 证书的新机器配置时，节点将重启。在下次引导过程中，服务 coreos-update-ca-trust.service 在 RHCOS 节点上运行，该节点上使用新的 CA 证书自动更新信任捆绑包。例如：

apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfig
metadata:
  labels:
    machineconfiguration.openshift.io/role: worker
  name: 50-examplecorp-ca-cert
spec:
  config:
    ignition:
      version: 2.2.0
    storage:
      files:
      - contents:
          source: data:text/plain;charset=utf-8;base64,LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUVORENDQXh5Z0F3SUJBZ0lKQU51bkkwRDY2MmNuTUEwR0NTcUdTSWIzRFFFQkN3VUFNSUdsTVFzd0NRWUQKV1FRR0V3SlZVekVYTUJVR0ExVUVDQXdPVG05eWRHZ2dRMkZ5YjJ4cGJtRXhFREFPQmdOVkJBY01CMUpoYkdWcApBMmd4RmpBVUJnTlZCQW9NRFZKbFpDQklZWFFzSUVsdVl5NHhFekFSQmdOVkJBc01DbEpsWkNCSVlYUWdTVlF4Ckh6QVpCZ05WQkFNTUVsSmxaQ0JJWVhRZ1NWUWdVbTl2ZENCRFFURWhNQjhHQ1NxR1NJYjNEUUVKQVJZU2FXNW0KWGpDQnBURUxNQWtHQTFVRUJoTUNWVk14RnpBVkJnTlZCQWdNRGs1dmNuUm9JRU5oY205c2FXNWhNUkF3RGdZRApXUVFIREFkU1lXeGxhV2RvTVJZd0ZBWURWUVFLREExU1pXUWdTR0YwTENCSmJtTXVNUk13RVFZRFZRUUxEQXBTCkFXUWdTR0YwSUVsVU1Sc3dHUVlEVlFRRERCSlNaV1FnU0dGMElFbFVJRkp2YjNRZ1EwRXhJVEFmQmdrcWhraUcKMHcwQkNRRVdFbWx1Wm05elpXTkFjbVZrYUdGMExtTnZiVENDQVNJd0RRWUpLb1pJaHZjTkFRRUJCUUFEZ2dFUApCRENDQVFvQ2dnRUJBTFF0OU9KUWg2R0M1TFQxZzgwcU5oMHU1MEJRNHNaL3laOGFFVHh0KzVsblBWWDZNSEt6CmQvaTdsRHFUZlRjZkxMMm55VUJkMmZRRGsxQjBmeHJza2hHSUlaM2lmUDFQczRsdFRrdjhoUlNvYjNWdE5xU28KSHhrS2Z2RDJQS2pUUHhEUFdZeXJ1eTlpckxaaW9NZmZpM2kvZ0N1dDBaV3RBeU8zTVZINXFXRi9lbkt3Z1BFUwpZOXBvK1RkQ3ZSQi9SVU9iQmFNNzYxRWNyTFNNMUdxSE51ZVNmcW5obzNBakxRNmRCblBXbG82MzhabTFWZWJLCkNFTHloa0xXTVNGa0t3RG1uZTBqUTAyWTRnMDc1dkNLdkNzQ0F3RUFBYU5qTUdFd0hRWURWUjBPQkJZRUZIN1IKNXlDK1VlaElJUGV1TDhacXczUHpiZ2NaTUI4R0ExVWRJd1FZTUJhQUZIN1I0eUMrVWVoSUlQZXVMOFpxdzNQegpjZ2NaTUE4R0ExVWRFd0VCL3dRRk1BTUJBZjh3RGdZRFZSMFBBUUgvQkFRREFnR0dNQTBHQ1NxR1NJYjNEUUVCCkR3VUFBNElCQVFCRE52RDJWbTlzQTVBOUFsT0pSOCtlbjVYejloWGN4SkI1cGh4Y1pROGpGb0cwNFZzaHZkMGUKTUVuVXJNY2ZGZ0laNG5qTUtUUUNNNFpGVVBBaWV5THg0ZjUySHVEb3BwM2U1SnlJTWZXK0tGY05JcEt3Q3NhawpwU29LdElVT3NVSks3cUJWWnhjckl5ZVFWMnFjWU9lWmh0UzV3QnFJd09BaEZ3bENFVDdaZTU4UUhtUzQ4c2xqCjVlVGtSaml2QWxFeHJGektjbGpDNGF4S1Fsbk92VkF6eitHbTMyVTB4UEJGNEJ5ZVBWeENKVUh3MVRzeVRtZWwKU3hORXA3eUhvWGN3bitmWG5hK3Q1SldoMWd4VVp0eTMKLS0tLS1FTkQgQ0VSVElGSUNBVEUtLS0tLQo=
        filesystem: root
        mode: 0644
        path: /etc/pki/ca-trust/source/anchors/examplecorp-ca.crt

机器的信任存储还必须支持更新节点的信任存储。

没有 Operator 可以自动更新 RHCOS 节点上的证书。

service-ca 是部署 OpenShift Container Platform 集群时创建自签名 CA 的一个 Operator。

不支持自定义过期条件。自签名 CA 存储在一个限定名为 service-ca/signing-key 的 secret 中。它在 tls.crt (certificate(s))、tls.key (private key) 和 ca-bundle.crt (CA bundle) 项中。

其他服务可通过使用 service.beta.openshift.io/serving-cert-secret-name: <secret name> 注解一个服务资源来请求一个 service serving 证书。作为响应，Operator 会为指定的 secret 生成一个新证书， tls.crt，以及一个私钥，tls.key。该证书的有效期为两年。

其他服务可通过使用 service.beta.openshift.io/inject-cabundle:true 注解来请求将服务 CA 的 CA 捆绑包注入 APIService 或 ConfigMap 资源，以支持通过服务 CA 生成的证书。作为响应，Operator 将其当前 CA 捆绑包写入 APIService 资源的 CABundle 字段，或将 service-ca.crt 写入配置映射。

自 OpenShift Container Platform 4.3.5 起，支持自动轮转，并将其向后移植到一些 4.2.z 和 4.3.z 版本中。对于任何支持自动轮转的版本，服务 CA 证书在 26 个月内有效，并在有效期少于 13 个月时进行刷新。如果需要，您可以手动刷新服务 CA。

服务 CA 26 个月的过期时间比支持的 OpenShift Container Platform 集群的预期升级间隔更长，因此使用服务 CA 证书的非 control plane 系统将会在 CA 轮转后刷新。这会发生在轮转前使用的 CA 过期前。

这些证书由系统而不是用户管理。

使用服务 CA 证书的服务包括：

这不是一个完整的列表。

其他资源

节点证书由集群签名; 证书来自由 bootstrap 过程生成的证书颁发机构 (CA)。安装集群后，节点证书会被自动轮转。

这些证书由系统而不是用户管理。

其他资源

OpenShift Container Platform 4 及之后的版本中的 kubelet 使用位于 /etc/kubernetes/kubeconfig 中的 bootstrap 证书来启动 bootstrap。然后是 bootstrap 初始化过程 和 kubelet 授权来创建一个 CSR。

在此过程中，kubelet 在通过 bootstrap 频道进行通信时会生成一个 CSR。控制器管理器为 CSR 签名，以生成 kubelet 管理的证书。

这些证书由系统而不是用户管理。

此 bootstrap CA 有效时间为 10 年。

kubelet 管理的证书的有效期为一年，并在一年经过了大约 80% 时进行自动轮转。

您无法自定义 bootstrap 证书。

etcd 证书由 etcd-signer 签名; 证书来自由 bootstrap 过程生成的证书颁发机构 (CA)。

CA 证书有效期为 10 年。对等证书、客户端证书和服务器证书的有效期为三年。

这些证书由系统而不是用户管理。

etcd 证书用于 etcd 对等成员间通信的加密，以及加密客户端流量。以下证书由 etcd 和其他与 etcd 通信的进程生成和使用：

其他资源

OpenShift Lifecycle Manager (OLM) 组件(olm-operator、catalog-operator、packageserver 和 marketplace-operator) 的所有证书均由系统管理。

安装在它们的 ClusterServiceVersion（CSV）对象中安装包含 webhook 或 API 服务的 Operator 时，OLM 会为这些资源创建和轮转证书。openshift-operator-lifecycle-manager 命名空间中的资源的证书由 OLM 管理。

OLM 不会更新它在代理环境中管理的 Operator 证书。这些证书必须由用户使用订阅配置进行管理。

应用程序通常通过 <route_name>.apps.<cluster_name>.<base_domain> 来公开。<cluster_name> 和 <base_domain> 来自安装配置文件。<route_name> 是路由的主机字段（如果指定）或路由名称。例如，hello-openshift-default.apps.username.devcluster.openshift.com。hello-openshift 是路由的名称，路由位于 default 命名空间。您可能希望客户端访问应用程序而无需向客户端发布集群管理的 CA 证书。在提供应用程序内容时，管理员必须设置自定义默认证书。

用户提供的证书必须在 openshift-ingress 命名空间中的 tls 类型 Secret 资源中提供。更新 openshift-ingress-operator 命名空间中的 IngressController CR，以启用用户提供的证书的使用。有关此过程的更多信息，请参阅设置自定义默认证书。

用户提供的证书由用户管理。

用户提供的证书由用户管理。

在集群中部署的应用程序使用用户提供的证书作为默认入口。

根据需要，更新包含用户管理的证书的 secret。

其他资源

Ingress Operator 使用以下证书：

为了保证对 Ingress Operator 和 Ingress Controller 指标的访问安全，Ingress Operator 使用 service serving 证书。Operator 为自己的指标从 service-ca 控制器请求证书，service-ca 控制器将证书放置在 openshift-ingress -operator 命名空间中的名为 metrics-tls 的 secret 中。另外，Ingress Operator 会为每个 Ingress Controller 请求一个证书，service-ca 控制器会将证书放在名为 router-metrics-certs-<name> 的 secret 中，其中 <name> 是 Ingress Controller 的名称（在 openshift-ingress 命名空间中）。

每个 Ingress Controller 都有一个默认证书，用于没有指定其自身证书的安全路由。除非指定了自定义证书，Operator 默认使用自签名证书。Operator 使用自己的自签名签名证书为其生成的任何默认证书签名。Operator 生成此签名证书，并将其置于 openshift-ingress-operator 命名空间中的名为 router-ca 的 secret 中。当 Operator 生成默认证书时，它会将默认证书放在 openshift-ingress 命名空间的名为 router-certs-<name>（其中 <name> 是 Ingress Controller 的名称）的 secret 中。

空的 defaultCertificate 项会使 Ingress Operator 使用它自己签名的 CA 来为指定的域生成 serving 证书。

Ingress Operator 生成的默认 CA 证书和密钥。用来为 Operator 生成的默认 serving 证书签名。

在默认工作流中，通配符默认服务证书，由 Ingress Operator 创建，并使用生成的默认 CA 证书签名。在自定义工作流中，这是用户提供的证书。

路由器部署。使用 secrets/router-certs-default 中的证书作为其默认前端服务器证书。

在默认工作流中，通配符默认服务证书（公共和私有组件）的内容在此复制，以启用 OAuth 集成。在自定义工作流中，这是用户提供的证书。

包含 Operator 生成的默认 CA 证书（公共部分）的资源; 由 OAuth 和 Web 控制台读取以建立信任。这个对象将在以后的发行版本中被删除。

默认服务证书的公共（certificate）部分。替换 configmaps/router-ca 资源。

用户使用对 ingresscontroller serving 证书签名的 CA 证书更新集群代理配置。这可让 auth、console 和 registry 等组件信任 serving 证书。

包含合并的 Red Hat Enterprise Linux CoreOS (RHCOS) 和用户提供的 CA 捆绑包（如果未提供用户捆绑包）的集群范围可信 CA 捆绑包。

自定义 CA 证书捆绑包,用于指示其他组件（如 auth 和 console）信任配置了自定义证书的 ingresscontroller。

trustedCA 字段用来引用用户提供的 CA 捆绑包。

Cluster Network Operator 将可信 CA 捆绑包注入 proxy-ca 配置映射。

在 OpenShift Container Platform 4.4 中,有些组件正在从使用 router-ca 转换为使用 default-ingress-cert。

Ingress Operator 证书的过期条件如下：

您不能自定义 Ingress Operator 或 service-ca 控制器创建的证书的过期条款。

安装 OpenShift Container Platform 时，不能为 Ingress Operator 或 service-ca 控制器创建的证书指定过期条款。

Prometheus 使用的用来确保指标安全的证书。

Ingress Operator 使用它的签名证书来为 Ingress Controller 签名默认证书，您不要为其设置自定义默认证书。

使用安全路由的集群组件可使用默认 Ingress Controller 默认证书。

通过安全路由进入集群的入口使用 Ingress Controller 的默认证书，该证书将访问该路由，除非该路由指定了自己的证书。

入口证书由用户管理。如需更多信息，请参阅替换默认入口证书。

service-ca 控制器自动轮转其发放的证书。但是，可以使用 oc delete secret <secret> 来手动轮转 service serving 证书。

Ingress Operator 不轮转其自身的签名证书或它生成的默认证书。Operator 生成的默认证书的目的是作为您配置的自定义默认证书的占位者。

监控组件使用服务 CA 证书保护其流量。这些证书有效 2 年，并可在服务 CA 轮转时自动替换。轮转每每 13 个月进行一次。

如果证书在 openshift-monitoring 或 openshift-logging 命名空间中，它会被自动管理并轮转。

这些证书由系统而不是用户管理。

Control plane 证书包括在这些命名空间中：

Control plane 证书由系统管理并自动轮转。

当 control plane 证书出现罕见的过期情形时，请参阅 恢复过期的 control plane 证书