Red Hat Summit 红帽全球峰会支持控制台（Console）开发人员开始试用联系人

Red Hat Trusted Application Pipeline 入门

Red Hat Trusted Application Pipeline 1.3

了解如何使用红帽受信任的应用程序管道。

Red Hat Trusted Application Pipeline Documentation Team

摘要

本文档提供了有关使用现成的软件模板来构建带有安全供应链功能的应用程序，如签名、测试、软件 Bill of Materials (SBOM)、SLSA 验证、CVE 扫描和发布策略保护rails。

前言
复制链接

借助 RHTAP，您将开始接待传统安全措施，集成尖端解决方案和 DevSecOps CI/CD 框架，实现部署。这种主动策略可加速开发人员加入、流程加速，以及安全从开始的嵌入。

第 1 章 开发工作流
复制链接

开发工作流包括创建、更新、保护和部署应用程序。它还允许与各种存储库、容器 registry 和 CI/CD 工具集成以实现灵活性。

Expand
步骤描述

安装 RHTAP

安装 RHTAP 以启用安全而有效的 DevSecOps 工作流。

创建应用程序

使用预构建的模板来创建应用程序。这些模板可以自定义，并包括管道和配置来简化开发过程。在创建应用程序时，您可以选择：

  • GitHub （默认）、Gitlab 或 Bitbucket 存储库
  • Quay （默认）或 Jfrog Artifactory (registry)
  • Tekton （默认）、GitHub Actions、Jenkins CI 或 GitLab CI （用于 CI/CD 工作流）
注意

如果在应用程序设置过程中选择了 Bitbucket、GitLab CI 或 Jenkins CI，您必须配置这些工具来触发管道运行。

更新应用程序

将更新推送到应用程序代码。管道会自动处理并保护更改。

查看安全见解

管道运行提供所有任务的可视化表示，提供有关安全检查和合规性的见解。

部署应用程序

将您的应用程序从 Development 提升到 Staging，然后提升到 Production 环境。

（可选）自定义模板和管道

修改模板和管道，以满足您机构的特定要求。

第 2 章 使用示例软件模板构建应用程序
复制链接

RHTAP 的现成软件模板包括与关键技术进行默认集成，以保护和优化您的开发体验：

  • ACS （高级集群安全）： 在开发过程中尽早识别和缓解漏洞，增强应用程序从入侵到部署。
  • Quay： 作为容器镜像的安全隐患，持续扫描漏洞，以使容器化应用程序安全。
  • Tekton Pipelines： 自动化构建和部署流程，提供一个 CI/CD 框架，无缝集成到 SDLC 中，并加速您的生产路径。
  • GitOps： 在 Git 存储库中维护您的基础架构和应用程序配置，确保所有环境中保持一致和自动部署。

此外，RHTAP 支持使用 Java、Python、Node.js 和 Go 等流行编程语言的开发和容器化应用程序。

注意

安装 RHTAP 后，集群管理员可以使用特定的模板和增强自定义 Red Hat Developer Hub 门户。但是，在自定义之前，集群管理员应熟悉可用的软件和管道模板。了解这些模板是获取 RHTAP 如何支持安全供应链的关键，为后续自定义打下基础。

2.1. 设置阶段
复制链接

  • 确保您已成功安装了 RHTAP。

  • 使用安装过程末尾的 RHTAP 安装程序提供的链接，登录 Red Hat Developer Hub (RHDH)。

2.2. 构建应用程序
复制链接

在 RHDH 门户上，选择 Create，然后选择合适的模板。例如，Quarkus Java - Trusted Application Pipeline。

使用 RHTAP 提供的模板在 RHDH 中为您的开发人员构建应用程序或微服务涉及三个主要步骤：

  • 提供应用程序信息
  • 提供应用程序存储库信息
  • 提供部署信息
提供应用程序信息
  1. 在 Name 字段中，提供应用程序名称。您的名称可以包含小写字母(a-z)、数字(0-9)和短划线(-)，但它必须以小写字母数字字符开头和结尾。有效名称的示例为 my-name 或 abc-123，长度范围为 1 到 63 个字符。
  2. 从 Owner 下拉列表中，为这个应用程序选择适当的 RHDH 组件所有者。默认值为 user:guest，它会在系统中没有注册特定所有者时显示。如果您还没有注册所有者，请保留默认的 user:guest 选择。您可以将 guest 替换为您的用户名，以个性化应用程序的所有权。
  3. 选择 Next。系统显示 Application Repository Information 表单。
提供应用程序存储库信息

  1. 从 Host Type 下拉列表中选择一个存储库主机类型：

    • GitHub
    • GitLab
    • Bitbucket
  2. 在 Repository Name 字段中，使用 A-Z、a-z、0-9、下划线(_)和短划线(-)输入存储库名称。系统将这个名称用于它在主机仓库服务器上创建的存储库。
  3. 在 Repository Owner 字段中，指定拥有 Git 存储库的机构中的用户名、机构名称或项目。例如，在 Bitbucket 中，您可以通过进入到 Personal Bitbucket 设置来查找您的用户名。

  4. 在 Repository Server 字段中，指定存储库服务器：

    Expand
    如果您选择 Host 类型描述

    GitHub

    该字段已预先填充 github.com。但是，您可以在没有 HTTP 协议的情况下输入内部主机 URL，而无需 .git 扩展。例如： github-github.apps.cluster-ljg9z.sandbox219.opentlc.com。

    GitLab

    该字段已预先填充 gitlab.com。但是，您可以在没有 HTTP 协议的情况下输入内部主机 URL，而无需 .git 扩展。例如，gitlab-gitlab.apps.cluster-ljg9z.sandbox219.opentlc.com.

    Bitbucket

    该字段已预先填充 bitbucket.org。

  5. 在 Repository Default Branch 字段中，为您的存储库指定默认分支。默认值为 main，但您可以指定不同的分支名称。

  6. 仅限 Bitbucket：

    1. 在 Workspace 字段中输入包含项目的工作区的名称。
    2. 在 Project 字段中，输入项目密钥。项目密钥位于 Bitbucket 中的项目名称旁边。

  7. 从 CI Provider 下拉列表中，选择系统用来构建、测试和部署应用程序的持续集成(CI)工具：

    Expand
    对于主机类型可用的 CI 供应商

    Bitbucket

    • Jenkins (SLSA 2)
    • Tekton (SLSA 3)

    GitHub

    • Jenkins (SLSA 2)
    • GitHub Actions (SLSA 2) （技术预览）
    • Tekton (SLSA 3)

    GitLab

    • Jenkins (SLSA 2)
    • GitLab CI (SLSA 2)
    • Tekton (SLSA 3)
    重要

    完成创建应用程序后：

    • 如果将 Bitbucket 选为源存储库和 Tekton 作为 CI，您必须在 Bitbucket 中添加 webhook。
    • 如果选择 GitLab CI，您必须配置所需的 secret。
    • 如果选择 Jenkins，您必须将应用添加到 Jenkins 中。
  8. 选择 Next。系统显示 Deployment Information 表单。
提供部署信息
  1. 在 Image Registry 字段中，指定没有 HTTP 协议的内部镜像 registry URL。支持注册表包括 Quay （如 quay.io）和 JFrog Artifactory （如 tssc.jfrog.io）。
  2. 在 Image Organization 字段中，为在第 1 步中提供的镜像 registry 输入镜像机构。

  3. 在 Image Name 字段中，使用小写字母、数字和分隔符输入镜像名称。分隔符包含一个句点(.)，最多两个下划线(_)或一个或多个连字符(-)。例如，my-app_1.2。

    注意

    您必须确保名称不以分隔符开头或结尾。

  4. 在 Deployment Namespace 字段中，输入您要部署应用程序的命名空间或集群的前缀。系统将命名空间创建为 rhtap-app-development、rhtap-app-stage 和 rhtap-app-prod。

    注意

    rhtap-app 是默认的部署命名空间前缀。集群管理员可以自定义此前缀。有关如何自定义默认部署命名空间前缀的说明，请参阅自定义示例软件模板。

  5. 选择 Review 来查看您添加的所有信息。

  6. 选择 Create。RHTAP 启动自动化任务来设置应用程序的基础架构和部署管道，包括：

    • 仓库 创建和配置 ： 在指定的托管服务中创建新存储库，包括 GitOps 存储库和源存储库。
    • Argo CD Integration ： 创建和配置 Argo CD 资源，以便在指定的命名空间间编配应用程序的部署。
    • 命名空间创建 ： 为开发、临时和生产环境生成命名空间。
    • 管道定义： 添加管道定义，提供用于构建、测试和部署应用程序的"Pipelines as Code"模型。

2.3. 查看应用程序
复制链接

使用 RHTAP 创建应用程序后，您可以查看其组件、源代码、GitOps 配置和相关文档。

快速分析

对于快速查看，点 "Run of …​" 页面中显示的链接。这些链接提供对重要资源的访问，例如：

  • 源存储库
  • GitOps 软件仓库

全面的分析

要详细分析，请按照以下步骤执行：

  • 选择 Open Component in catalog 或导航到 Catalog，其中列出了新创建的应用程序。

  • 检查源代码：

    1. 前往 Overview 选项卡，再选择 View Source 以打开包含应用程序源代码的存储库。

  • 查看部署历史记录：

    1. 在 Overview 选项卡中，导航到 Deployment summary 部分，以检查应用程序的跨命名空间部署。选择任何 Argo CD 应用程序来查看 Argo CD 中的部署详情，或者点击 Revision 列中的提交 ID 以查看 GitLab 或 GitHub 中的更改。

  • 查看 GitOps 存储库：

    1. 在 Overview 选项卡上，使用 Kind 下拉菜单选择 Resource 并查找相关的 GitOps 存储库。
    2. 选择 View Source 以直接检查 GitOps 配置。或者，对于包括技术文档的更广泛概述，请从 Catalog 部分选择 View TechDocs，然后选择 Home > Repository 下的 GitOps 存储库。

  • 查看文档：

    1. 在 Overview 选项卡中，选择 View Tech Docs。这会为您的应用程序打开技术文档，详细介绍了其功能、配置步骤和使用方法。

2.4. （可选） 取消注册应用程序
复制链接

这个过程从目录和资源视图中删除应用程序的源和 GitOps 存储库，基本上会隐藏它。应用程序在集群中保持正常工作。您可以随时重新注册未注册的应用程序。

  1. 进入到 Catalog，再选择您要取消注册的组件。

  2. 选择与组件关联的垂直三点菜单，然后选择 Unregister entity。系统会显示一个确认对话框。

    unregister
    View larger image
    unregister
  3. 选择 Unregister Location。这会从目录视图中删除应用程序的 Git 存储库。
  4. 导航到 Catalog，从 Kind 下拉列表中选择 Resource，然后取消注册对应的 GitOps 资源。

  5. 运行以下命令从集群中删除应用程序： 

    oc delete application your-app-name-app-of-apps -n rhtap
    1
    Copy to Clipboard Toggle word wrap
    1
    如果不同，将 rhtap 替换为您的命名空间，并将 your-app-name 替换为应用程序的名称。

第 3 章 更新代码并查看安全分析
复制链接

使用 RHTAP 构建组件后，更新您的代码并查看安全见解。

3.1. 更新代码
复制链接

  1. 进入 Catalog，再选择您要修改的组件。

  2. 在 Overview 选项卡上，选择 View Source 选项卡，以在 GitLab 或 GitHub 中打开您的项目。

    1. 您还可以选择 View Tech Docs 查看您的项目的文档。文档源位于存储库中的 docs 目录中。对这些文件的更新会触发管道运行，它会刷新 Tech Docs。

  3. 对您的代码进行更改。

    1. 克隆您的存储库。
    2. 修改应用程序。例如，更新技术文档或 index.html。
    3. 提交并推送您的更改。
    注意
    • 您还可以使用 GitLab 或 GitHub UI 来直接在 web 界面中更新您的代码。
    • 仅限 GitLab 用户： 您必须在 GitLab 中设置 webhook 和 secret，以便在代码更新时自动触发管道运行。有关在 GitLab 中设置 webhook 和 secret 的详情，请参考为安全集成设置 GitLab。

3.2. 查看管道运行
复制链接

  1. 打开 RHDH，导航到 Catalog，然后选择修改的组件。
  2. 选择 CI 选项卡来查看管道运行详情。
  3. （可选）选择 CD 选项卡以深入了解由 ArgoCD 和 GitOps 管理的部署。
  4. （可选）选择 Topology 选项卡，在 development 命名空间中视觉化应用程序的部署。

3.3. 查看安全见解
复制链接

当您更新代码和推送更改时，系统会自动触发 on-push 管道。默认情况下，RHTAP 使用标准构建管道进行容器化部署，以满足 软件工件(SLSA)级别 3 规范。

图 3.1. 管道运行成功

Pipeline 运行
View larger image
Pipeline 运行

管道运行执行以下任务：

  • init ：配置重建标志、身份验证并创建镜像存储库 secret。
  • clone-repository ：克隆存储库以准备构建。

  • build-container ：

    • 使用 Buildah 从源代码创建容器镜像并将其推送到 registry。
    • 生成软件 Bill of Materials (SBOM)以记录所有组件和依赖项。
    • 发布安全工件，如镜像签名和测试。
  • update-deployment ：更新 GitOps 存储库来部署新镜像。
  • ACS tasks：运行安全检查以确保遵守策略。
  • show-sbom ：列出所有软件组件和库以透明。
  • Summary : 清理资源并提供管道运行摘要。
注意

点管道运行中的任何任务来查看日志。

3.3.1. 高级集群安全任务
复制链接

只有在 RHTAP 安装过程中安装和配置 ACS 时，管道中的 ACS 任务才会成功。如果没有安装或配置 ACS，管道将跳过这些任务。

注意

图 3.2. 管道运行中的 ACS 任务

ACS 任务
View larger image
ACS 任务

管道包括三个 ACS 任务，它们使用 roxctl 执行安全检查：

  • roxctl 镜像 scan - 识别镜像中的组件和漏洞，并以 JSON 格式返回结果。
  • roxctl image check - Verifies build-time security violations in the image。例如，策略（如 'No log4j allowed'）或限制在生产镜像中包括 curl、wget 或软件包管理器。
  • roxctl 部署检查 - 检查 YAML 部署文件中的构建时间和部署时间安全违反情况。
视觉化 ACS 报告

在 RHDH 中，在 CI 选项卡下，Pipeline Runs 部分会在结构化弹出界面中显示详细的任务报告。弹出窗口包括：

  • 高级 Cluster Security （条件在 ACS 任务可用性上显示）： 显示所有 ACS 任务的独立选项卡，以及汇总发现的安全问题。
  • 其他： 提供 PipelineRun 的结果，如 IMAGE_URL 和 IMAGE_DIGEST。只有在弹出窗口中提供了多个部分（例如，企业合同或 {RHACSLongName}）时，才会显示本节。

查看 ACS 报告：

  1. 选择 Catalog 并选择您要查看的组件。

  2. 选择 CI 选项卡 > Actions column > View output 图标，并查看所选组件的详细 ACS 报告。

    图 3.3. 详细的 ACS 报告

    ACS 报告
    View larger image
    ACS 报告
    注意

    如果您有所需的权限，您可以管理漏洞、策略，并查看 ACS 控制台中特定镜像的详细漏洞报告。如需更多信息，请参阅 查看仪表板。

解释 ACS 报告

ACS 任务报告提供在维护强大的安全状况时至关重要的安全分析。

以下是解释 roxctl 镜像扫描 (Image Scan)报告的示例。对 roxctl 镜像检查 (Image Check)和 roxctl 部署检查 (Deployment Check)报告使用相同的方法。

  • 漏洞明细： ACS 检测到的漏洞按严重性(Critical、重要、中等、低)、状态（可修复、不可修复）进行分类，并提供扫描结果概述。这种分类包括分析的漏洞和组件总数，以及标识的特定常见漏洞和风险(CVE)。

  • Details Provided: 对于每个识别的漏洞，报告包括：

    • CVE ID ： 漏洞的唯一标识符。
    • 严重性 ： 漏洞构成的威胁级别。
    • 组件 ： 受漏洞影响的软件组件。
    • 组件版本： 受影响组件的版本。
    • 补救建议： 建议解决漏洞，包括修复漏洞的版本（如果适用）。

3.3.2. 了解 SBOM
复制链接

show-sbom 任务创建应用中使用的所有软件库的列表。这有助于识别漏洞并评估安全问题。

图 3.4. 管道运行中的 show-sbom 任务

sbom
View larger image
sbom
查看 SBOM

流程

  1. 选择 Catalog 并选择组件。

  2. 选择 CI 选项卡，然后选择 show-sbom 任务的链接图标。系统显示 SBOM 任务日志。查看浏览器中的 SBOM 并搜索漏洞，如 log4j。

    图 3.5. SBOM 详情

    show sbom
    View larger image
    show sbom
在 CLI 中下载 SBOM

先决条件

  • 已安装 Cosign CLI 工具。
  • build-container 和 show-sbom 任务成功运行。

流程

  1. 扩展成功的管道运行并选择 show-summary 任务。

  2. 搜索并复制 SBOM 镜像 URL，然后在终端中运行以下命令：

    cosign 命令示例

    $ cosign download sbom <the-sbom-url-you-copied>
    Copy to Clipboard Toggle word wrap

    1. （可选）将输出保存到文件中，以便详细分析：

      cosign 命令示例

      $ cosign download sbom <the-sbom-url-you-copied> > sbom.txt
      Copy to Clipboard Toggle word wrap

解释 SBOMs

SBOM 包括项目中使用的每个库的信息，例如：

  • 库源、作者或发布者
  • 库名称
  • 库版本
  • 许可证类型

这些信息有助于确保单个库安全源、更新并合规。

SBOM 示例

{
    "bomFormat": "CycloneDX",
    "specVersion": "1.4",
    "serialNumber": "urn:uuid:89146fc4-342f-496b-9cc9-07a6a1554220",
    "version": 1,
    "metadata": {
        ...
    },
    "components": [
        {
            "bom-ref": "pkg:pypi/flask@2.1.0?package-id=d6ad7ed5aac04a8",
            "type": "library",
            "author": "Armin Ronacher <armin.ronacher@active-4.com>",
            "name": "Flask",
            "version": "2.1.0",
            "licenses": [
                {
                    "license": {
                        "id": "BSD-3-Clause"
                    }
                }
            ],
            "cpe": "cpe:2.3:a:armin-ronacher:python-Flask:2.1.0:*:*:*:*:*:*:*",
            "purl": "pkg:pypi/Flask@2.1.0",
            "properties": [
                {
                    "name": "syft:package:foundBy",
                    "value": "python-package-cataloger"
                    ...
Copy to Clipboard Toggle word wrap

第 4 章 部署应用程序并查看安全见解
复制链接

在 OpenShift GitOps 中使用 Argo CD 部署应用程序以启用 continuos 部署。Argo CD 使用 Git 存储库作为基础架构配置的单个数据源。更新存储库会在开发、临时和生产环境中触发部署。

注意

该流程提供了一个示例部署工作流。对其进行自定义，以符合您组织的需求。

4.1. 将构建提升到预生产环境或生产环境
复制链接

通过拉取请求(PR)更新 GitOps 存储库来提升构建。

  1. 在 RHDH 中，选择 Catalog。
  2. 从 Kind 下拉列表中，选择 Resource，然后选择 GitOps 存储库。
  3. 打开 Overview 选项卡，再选择 View Source 以访问存储库。

  4. （可选）或者选择 Catalog，打开 Overview 选项卡，然后选择 View TechDocs。

    1. 在 Home > Repository 部分中，选择 GitOps 存储库。

  5. 克隆您的 GitOps 存储库。

    注意

    确保本地克隆为最新版本。

  6. 创建新分支。
  7. 导航到 component/<app-name>/overlays 目录，其中包含 用于开发、stage 和 prod 的子目录。

  8. 按照以下步骤提升应用程序：

    Expand
    移动应用程序执行此操作

    从开发到暂存环境

    1. 打开 th development/deployment-patch.yaml 文件并复制容器镜像 URL。例如： quay.io/<username>/imageName:imageHash。
    2. 打开 stage/deployment-patch.yaml 文件，并将容器镜像 URL 替换为您复制的文件。
    注意

    要包括额外的配置更改（如副本），请将它们从 development/deployment-patch.yaml 文件复制到 stage/deployment-patch.yaml 文件中。

    从阶段到生产环境

    1. 打开 stage/deployment-patch.yaml 文件，并复制容器镜像 URL。例如： quay.io/<username>/imageName:imageHash。
    2. 打开 prod/deployment-patch.yaml 文件，并将容器镜像 URL 替换为您复制的文件。
    注意

    要包括额外的配置更改（如副本），请将它们从 stage/deployment-patch.yaml 文件复制到 prod/deployment-patch.yaml 文件中。

  9. 提交并推送您的更新。

  10. 创建一个 PR 以开始提升管道。管道会根据 Red Hat Enterprise Contract （企业合同）策略验证更改。

    1. 在 RHDH 的 CI 选项卡中检查管道运行。
  11. 合并 PR 触发 Argo CD，这将应用更改，并将构建提升到下一个环境。

验证

  • 使用 RHDH 中的 Topology 选项卡确认应用程序分布在命名空间间。
  • 使用 CD 选项卡查看部署详情，包括状态、更新、提交消息（如 Promote stage 到 prod），以及容器镜像更改。

4.2. 查看安全见解
复制链接

提升管道包括几个任务，以确保安全兼容部署。管道任务包括：

  • git-clone ： 使用 git-clone 任务将存储库克隆到工作区中。
  • gather-deploy-images ： 从部署 YAML 文件中提取容器镜像进行验证。
  • verify-enterprise-contract ： 使用企业合同(EC)策略和 Sigstore 的 cosign 工具验证容器镜像。
  • deploy-images ： 部署将镜像验证到目标环境中。
  • download-sbom-from-url-in-attestations : 通过下载在测试时引用的 OCI blob，为镜像检索 SBOMs。
  • upload-sbom-to-trustification: Uploads SBOMs to Trustification using the BOMbastic API。

4.2.1. 企业合同任务
复制链接

企业合同(EC)是专为维护软件供应链安全的工具套件。它通过在提升到生产环境之前验证是否满足定义的要求，从而帮助保持容器镜像的完整性。如果镜像不遵循集合策略，则 EC 会生成一个报告，用于标识必须解决的问题。

Red Hat Trusted Application Pipeline 构建过程使用 Tekton 链 来生成 构建管道 签名的签名。这些认证时，会以加密方式验证构建的完整性。然后，EC 会根据定义的策略评估构建，确保它符合机构的安全标准。

解释合规性报告

EC 合规性报告提供有关应用程序安全性并遵循策略的详细见解。要了解如何了解这些报告：

  • 策略合规概述： 显示执行的检查、状态、（成功、警告或失败）以及解释警告或失败的消息。

  • 提供了详情： 策略报告详情：

    • 成功检查 ：列出通过验证的策略。
    • 警告和失败 ：突出显示触发警告或失败的检查的策略，解释。
    • 规则合规性 ：显示应用程序如何遵循各个策略规则，如源代码引用或测试验证。

图 4.1. EC 报告

企业合同
View larger image
企业合同
使用合规性分析

EC 合规报告的见解有助于优先选择安全性和合规性任务：

  • 审查策略合规性： 确保您的应用程序符合 Supply Chain Levels for Software Artifacts (SLSA)等标准。根据报告中的建议解决任何合规性差距。
  • 简化回顾： 在报告中使用过滤器来专注于关键问题，实现更快速、高效的审查过程。





更新于 2024-12-16

法律通告
复制链接

Copyright © 2024 Red Hat, Inc.
The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at http://creativecommons.org/licenses/by-sa/3.0/. In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version.
Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.
Red Hat, Red Hat Enterprise Linux, the Shadowman logo, the Red Hat logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
Java® is a registered trademark of Oracle and/or its affiliates.
XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
Node.js® is an official trademark of Joyent. Red Hat is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.
The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation's permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.
All other trademarks are the property of their respective owners.
返回顶部
Red Hat logoGithubredditYoutubeTwitter

学习

尝试、购买和销售

社区

关于红帽文档

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

让开源更具包容性

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

關於紅帽

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

Theme

© 2025 Red Hat