保护 OpenShift Pipelines


Red Hat OpenShift Pipelines 1.10

OpenShift Pipelines 的安全功能

Red Hat OpenShift Documentation Team

摘要

本文档提供有关 OpenShift Pipelines 的安全功能的信息。

重要

Tekton 链只是一个技术预览功能。技术预览功能不受红帽产品服务等级协议(SLA)支持,且功能可能并不完整。红帽不推荐在生产环境中使用它们。这些技术预览功能可以使用户提早试用新的功能,并有机会在开发阶段提供反馈意见。

有关红帽技术预览功能支持范围的更多信息,请参阅技术预览功能支持范围

Tekton Chains 是一个 Kubernetes 自定义资源定义(CRD)控制器。您可以使用它来管理使用 Red Hat OpenShift Pipelines 创建的任务和管道的供应链安全。

默认情况下,Tekton Chains 会观察 OpenShift Container Platform 集群中的所有任务运行执行。当任务运行完成时,Tekton Chains 会获取任务运行的快照。然后,它会将快照转换为一个或多个标准有效负载格式,最后签署并存储所有工件。

要捕获有关任务运行的信息,Tekton Chains 使用 ResultPipelineResource 对象。当对象不可用时,Tekton 会链 OCI 镜像的 URL 和合格摘要。

注意

PipelineResource 对象已弃用,并将在以后的发行版本中删除 ; 对于手动使用,建议使用 Results 对象。

1.1. 主要特性

  • 您可以使用诸如 cosign 等工具生成的加密密钥为任务运行、任务运行结果和 OCI registry 镜像签名。
  • 您可以使用"测试"格式,如 in-toto
  • 您可以使用 OCI 存储库作为存储后端安全存储签名和签名工件。

集群管理员可以使用 TektonChain 自定义资源(CR)来安装和管理 Tekton 链。

注意

Tekton Chains 是 Red Hat OpenShift Pipelines 的一个可选组件。目前,您无法使用 TektonConfig CR 安装它。

先决条件

  • 确保在集群中的 openshift-pipelines 命名空间中安装了 Red Hat OpenShift Pipelines Operator。

流程

  1. 为 Red Hat OpenShift Pipelines 集群创建 TektonChain CR。

    apiVersion: operator.tekton.dev/v1alpha1
    kind: TektonChain
    metadata:
      name: chain
    spec:
      targetNamespace: openshift-pipelines
    Copy to Clipboard Toggle word wrap
  2. 应用 TektonChain CR。

    $ oc apply -f TektonChain.yaml 
    1
    Copy to Clipboard Toggle word wrap
    1
    使用 TektonChain CR 的文件名替换。
  3. 检查安装的状态。

    $ oc get tektonchains.operator.tekton.dev
    Copy to Clipboard Toggle word wrap

1.3. 配置 Tekton 链

Tekton Chains 在 openshift-pipelines 命名空间中使用名为 chains-configConfigMap 对象进行配置。

要配置 Tekton 链,请使用以下示例:

示例:配置 Tekton 链

$ oc patch configmap chains-config -n openshift-pipelines -p='{"data":{"artifacts.oci.storage": "", "artifacts.taskrun.format":"tekton", "artifacts.taskrun.storage": "tekton"}}' 
1
Copy to Clipboard Toggle word wrap

1
在 JSON 有效负载中使用支持的键值对组合。

1.3.1. Tekton Chains 配置支持的键

集群管理员可以使用各种支持的键和值来配置任务运行、OCI 镜像和存储的规格。

1.3.1.1. 任务运行支持的键
Expand
表 1.1. 链配置:任务运行支持的密钥
支持的键描述支持的值默认值

artifacts.taskrun.format

存储任务运行有效负载的格式。

tekton, in-toto

tekton

artifacts.taskrun.storage

任务运行签名的存储后端。您可以将多个后端指定为用逗号分开的列表,如 “tekton,oci”。要禁用此工件,请提供一个空字符串 ""

tekton, oci

tekton

artifacts.taskrun.signer

签名后端为任务运行有效负载进行签名。

x509

x509

1.3.1.2. OCI 支持的密钥
Expand
表 1.2. 链配置: OCI 支持的密钥
支持的键描述支持的值默认值

artifacts.oci.format

存储 OCI 有效负载的格式。

simplesigning

simplesigning

artifacts.oci.storage

OCI 签名的存储后端。您可以将多个后端指定为用逗号分开的列表,如 “oci,tekton”。要禁用 OCI 工件,请提供空字符串 ""

tekton, oci

oci

artifacts.oci.signer

签名后端以签署 OCI 有效负载。

x509,cosign

x509

1.3.1.3. 支持的存储密钥
Expand
表 1.3. 链配置:存储支持的密钥
支持的键描述支持的值默认值

artifacts.oci.repository

用于存储 OCI 签名的 OCI 存储库。

目前,链仅支持内部 OpenShift OCI registry;不支持 Quay 等其他流行选项。

 

1.4. 在 Tekton Chains 中签名 secret

集群管理员可以生成密钥对,并使用 Tekton 链来使用 Kubernetes secret 为工件签名。要使 Tekton 链正常工作,加密的密钥和密码必须作为 openshift-pipelines 命名空间中的 signing-secrets Kubernetes secret 的一部分存在。

目前,Tekton 链支持 x509cosign 签名方案。

注意

只使用一个受支持的签名方案。

1.4.1. 使用 x509 进行签名

要将 x509 签名方案与 Tekton Chains 搭配使用,请将 ed25519ecdsa 类型的 x509.pem 私钥存储在 signing-secrets Kubernetes secret 中。确保密钥保存为未加密的 PKCS8 PEM 文件(BEGIN PRIVATE KEY)。

1.4.2. 使用 cosign 进行签名

使用 Tekton 链的 cosign 签名方案:

  1. 安装 cosign
  2. 生成 cosign.keycosign.pub 密钥对。

    $ cosign generate-key-pair k8s://openshift-pipelines/signing-secrets
    Copy to Clipboard Toggle word wrap

    Cosign 提示您输入密码,并创建一个 Kubernetes secret。

  3. 将加密的 cosign.key 私钥和 cosign.password 解密密码存储在 signing-secrets Kubernetes secret 中。确保私钥存储为 ENCRYPTED COSIGN PRIVATE KEY 类型的加密 PEM 文件。

1.4.3. 签名故障排除

如果签名 secret 已填充,您可能会遇到以下错误:

Error from server (AlreadyExists): secrets "signing-secrets" already exists
Copy to Clipboard Toggle word wrap

要解决这个问题:

  1. 删除 secret:

    $ oc delete secret signing-secrets -n openshift-pipelines
    Copy to Clipboard Toggle word wrap
  2. 重新创建密钥对并使用您首选的签名方案将其存储在 secret 中。

1.5. 对 OCI registry 进行身份验证

在将签名推送到 OCI Registry 之前,集群管理员必须配置 Tekton 链,以便与 registry 进行身份验证。Tekton Chains 控制器使用与任务运行相同的服务帐户。要设置具有所需凭证(push)到 OCI registry 的服务帐户,请执行以下步骤:

流程

  1. 设置 Kubernetes 服务帐户的命名空间和名称。

    $ export NAMESPACE=<namespace> 
    1
    
    $ export SERVICE_ACCOUNT_NAME=<service_account> 
    2
    Copy to Clipboard Toggle word wrap
    1
    与服务帐户关联的命名空间。
    2
    服务帐户的名称。
  2. 创建 Kubernetes secret。

    $ oc create secret registry-credentials \
      --from-file=.dockerconfigjson \ 
    1
    
      --type=kubernetes.io/dockerconfigjson \
      -n $NAMESPACE
    Copy to Clipboard Toggle word wrap
    1
    使用 Docker 配置文件的路径替换。默认路径为 ~/.docker/config.json
  3. 授予服务帐户对 secret 的访问权限。

    $ oc patch serviceaccount $SERVICE_ACCOUNT_NAME \
      -p "{\"imagePullSecrets\": [{\"name\": \"registry-credentials\"}]}" -n $NAMESPACE
    Copy to Clipboard Toggle word wrap

    如果对 Red Hat OpenShift Pipelines 分配到所有任务的默认 pipeline 服务帐户进行补丁,Red Hat OpenShift Pipelines Operator 将覆盖服务帐户。作为最佳实践,您可以执行以下步骤:

    1. 创建单独的服务帐户,以分配给用户的任务运行。

      $ oc create serviceaccount <service_account_name>
      Copy to Clipboard Toggle word wrap
    2. 通过设置任务运行模板中的 serviceaccountname 字段的值,将服务帐户关联到运行任务。

      apiVersion: tekton.dev/v1beta1
      kind: TaskRun
      metadata:
      name: build-push-task-run-2
      spec:
      serviceAccountName: build-bot 
      1
      
      taskRef:
        name: build-push
      ...
      Copy to Clipboard Toggle word wrap
      1
      使用新创建的服务帐户的名称替换。

要验证使用 Tekton 链与任何其他身份验证一起运行的任务的签名,请执行以下任务:

  • 创建加密的 x509 密钥对,并将它保存为 Kubernetes secret。
  • 配置 Tekton Chains 后端存储。
  • 创建任务运行,为它签名并将签名和有效负载存储为任务运行自身时的注解。
  • 从已签名任务运行中检索签名和有效负载。
  • 验证任务运行的签名。

先决条件

确保在集群中安装了以下内容:

  • Red Hat OpenShift Pipelines Operator
  • Tekton Chains
  • Cosign

流程

  1. 创建加密的 x509 密钥对,并将它保存为 Kubernetes secret:

    $ cosign generate-key-pair k8s://openshift-pipelines/signing-secrets
    Copy to Clipboard Toggle word wrap

    提示时提供密码。Cosign 将生成的私钥存储为 openshift-pipelines 命名空间中的 signing-secrets Kubernetes secret 的一部分。

  2. 在 Tekton Chains 配置中,禁用 OCI 存储,并将任务运行存储和格式设置为 tekton

    $ oc patch configmap chains-config -n openshift-pipelines -p='{"data":{"artifacts.oci.storage": "", "artifacts.taskrun.format":"tekton", "artifacts.taskrun.storage": "tekton"}}'
    Copy to Clipboard Toggle word wrap
  3. 重启 Tekton Chains 控制器,以确保应用了修改后的配置。

    $ oc delete po -n openshift-pipelines -l app=tekton-chains-controller
    Copy to Clipboard Toggle word wrap
  4. 创建任务运行。

    $ oc create -f https://raw.githubusercontent.com/tektoncd/chains/main/examples/taskruns/task-output-image.yaml 
    1
    
    taskrun.tekton.dev/build-push-run-output-image-qbjvh created
    Copy to Clipboard Toggle word wrap
    1
    使用指向您的任务运行的 URI 或文件路径替换。
  5. 检查步骤的状态,并等待 till 进程完成。

    $ tkn tr describe --last
    [...truncated output...]
    NAME                            STATUS
    ∙ create-dir-builtimage-9467f   Completed
    ∙ git-source-sourcerepo-p2sk8   Completed
    ∙ build-and-push                Completed
    ∙ echo                          Completed
    ∙ image-digest-exporter-xlkn7   Completed
    Copy to Clipboard Toggle word wrap
  6. 从存储为 base64 编码注解的对象检索签名和有效负载:

    $ export TASKRUN_UID=$(tkn tr describe --last -o  jsonpath='{.metadata.uid}')
    $ tkn tr describe --last -o jsonpath="{.metadata.annotations.chains\.tekton\.dev/signature-taskrun-$TASKRUN_UID}" > signature
    $ tkn tr describe --last -o jsonpath="{.metadata.annotations.chains\.tekton\.dev/payload-taskrun-$TASKRUN_UID}" | base64 -d > payload
    Copy to Clipboard Toggle word wrap
  7. 验证签名。

    $ cosign verify-blob --key k8s://openshift-pipelines/signing-secrets --signature ./signature ./payload
    Verified OK
    Copy to Clipboard Toggle word wrap

1.6. 使用 Tekton 链来签名和验证镜像并证明

集群管理员可以通过执行以下任务来使用 Tekton 链来签名和验证镜像和验证镜像:

  • 创建加密的 x509 密钥对,并将它保存为 Kubernetes secret。
  • 为 OCI registry 设置身份验证,以在测试过程中存储镜像、镜像签名和签名的镜像。
  • 配置 Tekton 链以生成和签署认可。
  • 在任务运行中,使用 Kaniko 创建镜像。
  • 验证已签名的镜像及已签名证明。

先决条件

确保在集群中安装了以下内容:

  • Red Hat OpenShift Pipelines Operator
  • Tekton Chains
  • Cosign
  • Rekor
  • jq

流程

  1. 创建加密的 x509 密钥对,并将它保存为 Kubernetes secret:

    $ cosign generate-key-pair k8s://openshift-pipelines/signing-secrets
    Copy to Clipboard Toggle word wrap

    提示时提供密码。Cosign 将生成的私钥作为 openshift-pipelines 命名空间中的 signing-secrets Kubernetes secret 的一部分存储在 openshift-pipelines 命名空间中,并将公钥写入 cosign.pub 本地文件。

  2. 为镜像 registry 配置身份验证。

    1. 要将 Tekton Chains 控制器配置为将签名推送到 OCI registry,请使用与任务运行服务帐户关联的凭证。如需更多信息,请参阅"授权到 OCI registry"部分。
    2. 要为构建并推送到 registry 的 Kaniko 任务配置身份验证,请创建一个包含所需凭证的 docker config.json 文件的 Kubernetes secret。

      $ oc create secret generic <docker_config_secret_name> \ 
      1
      
        --from-file <path_to_config.json> 
      2
      Copy to Clipboard Toggle word wrap
      1
      使用 docker config secret 的名称替换。
      2
      使用 docker config.json 文件的路径替换。
  3. 通过在 chains-config 对象中设置 artifacts.taskrun.formatartifacts.taskrun.storagetransparency.enabled 参数来配置 Tekton 链 :

    $ oc patch configmap chains-config -n openshift-pipelines -p='{"data":{"artifacts.taskrun.format": "in-toto"}}'
    
    $ oc patch configmap chains-config -n openshift-pipelines -p='{"data":{"artifacts.taskrun.storage": "oci"}}'
    
    $ oc patch configmap chains-config -n openshift-pipelines -p='{"data":{"transparency.enabled": "true"}}'
    Copy to Clipboard Toggle word wrap
  4. 启动 Kaniko 任务。

    1. 将 Kaniko 任务应用到集群。

      $ oc apply -f examples/kaniko/kaniko.yaml 
      1
      Copy to Clipboard Toggle word wrap
      1
      使用 Kaniko 任务的 URI 或文件路径替换。
    2. 设置适当的环境变量。

      $ export REGISTRY=<url_of_registry> 
      1
      
      
      $ export DOCKERCONFIG_SECRET_NAME=<name_of_the_secret_in_docker_config_json> 
      2
      Copy to Clipboard Toggle word wrap
      1
      使用您要推送镜像的 registry 的 URL 替换。
      2
      使用 docker config.json 文件中的 secret 名称替换。
    3. 启动 Kaniko 任务。

      $ tkn task start --param IMAGE=$REGISTRY/kaniko-chains --use-param-defaults --workspace name=source,emptyDir="" --workspace name=dockerconfig,secret=$DOCKERCONFIG_SECRET_NAME kaniko-chains
      Copy to Clipboard Toggle word wrap

      观察此任务的日志,直到所有步骤都完成。身份验证成功后,最终镜像将推送到 $REGISTRY/kaniko-chains

  5. 等待一分钟,以允许 Tekton 链生成证据并对其进行签名,然后在任务运行时检查 chains.tekton.dev/signed=true 注解的可用性。

    $ oc get tr <task_run_name> \ 
    1
    
    -o json | jq -r .metadata.annotations
    
    {
      "chains.tekton.dev/signed": "true",
      ...
    }
    Copy to Clipboard Toggle word wrap
    1
    使用任务运行的名称替换。
  6. 验证镜像和 attestation。

    $ cosign verify --key cosign.pub $REGISTRY/kaniko-chains
    
    $ cosign verify-attestation --key cosign.pub $REGISTRY/kaniko-chains
    Copy to Clipboard Toggle word wrap
  7. 在 Rekor 中找到镜像的验证情况。

    1. 获取 $REGISTRY/kaniko-chains 镜像摘要。您可以搜索任务运行或拉取镜像以提取摘要。
    2. 搜索 Rekor 以查找与镜像 sha256 摘要匹配的所有条目。

      $ rekor-cli search --sha <image_digest> 
      1
      
      
      <uuid_1> 
      2
      
      <uuid_2> 
      3
      
      ...
      Copy to Clipboard Toggle word wrap
      1
      使用镜像的 sha256 摘要替换。
      2
      第一个匹配通用唯一标识符(UUID)。
      3
      第二个匹配 UUID。

      搜索结果显示匹配条目的 UUID。其中其中一个 UUID 包含 attestation。

    3. 检查 attestation。

      $ rekor-cli get --uuid <uuid> --format json | jq -r .Attestation | base64 --decode | jq
      Copy to Clipboard Toggle word wrap

第 2 章 在特权安全上下文中使用 pod

如果 Pod 由管道运行或任务运行,则 OpenShift Pipelines 1.3.x 及更新版本的默认配置不允许使用特权安全上下文运行 Pod。对于这样的容器集,默认服务帐户为 pipeline,与 pipelines 服务帐户关联的安全性上下文约束(SCC)是 pipelines-sccpipelines-scc SCC 与 anyuid SCC 类似,但存在细微差别,如管道 SCC 的 YAML 文件中定义:

pipelines-scc.yaml 片断示例

apiVersion: security.openshift.io/v1
kind: SecurityContextConstraints
...
allowedCapabilities:
  - SETFCAP
...
fsGroup:
  type: MustRunAs
...
Copy to Clipboard Toggle word wrap

另外,Buildah 集群任务作为 OpenShift Pipelines 的一部分提供,使用 vfs 作为默认存储驱动程序。

流程

要使用 特权 安全上下文运行 pod(从管道运行或任务运行中),请执行以下修改:

  • 将关联的用户帐户或服务帐户配置为具有显式 SCC。您可以使用以下任一方法执行配置:

    • 运行以下命令:

      $ oc adm policy add-scc-to-user <scc-name> -z <service-account-name>
      Copy to Clipboard Toggle word wrap
    • 或者,修改 RoleBindingRoleClusterRole 的 YAML 文件:

      RoleBinding 对象示例

      apiVersion: rbac.authorization.k8s.io/v1
      kind: RoleBinding
      metadata:
        name: service-account-name 
      1
      
        namespace: default
      roleRef:
        apiGroup: rbac.authorization.k8s.io
        kind: ClusterRole
        name: pipelines-scc-clusterrole 
      2
      
      subjects:
      - kind: ServiceAccount
        name: pipeline
        namespace: default
      Copy to Clipboard Toggle word wrap

      1
      使用适当的服务帐户名称替换。
      2
      根据您使用的角色绑定,使用适当的集群角色替换。

      ClusterRole 对象示例

      apiVersion: rbac.authorization.k8s.io/v1
      kind: ClusterRole
      metadata:
        name: pipelines-scc-clusterrole 
      1
      
      rules:
      - apiGroups:
        - security.openshift.io
        resourceNames:
        - nonroot
        resources:
        - securitycontextconstraints
        verbs:
        - use
      Copy to Clipboard Toggle word wrap

      1
      根据您使用的角色绑定,使用适当的集群角色替换。
    注意

    作为最佳实践,请创建默认 YAML 文件的副本并在重复文件中进行更改。

  • 如果您不使用 vfs 存储驱动程序,请将与任务运行或管道运行关联的服务帐户配置为具有特权 SCC,并将安全上下文设置为 privileged: true

使用与默认 pipelines 服务帐户关联的 pipelines-scc 安全性上下文约束(SCC)时,管道运行和任务运行 pod 可能会面临超时问题。这是因为在默认的 pipelines-scc SCC 中,fsGroup.type 参数设置为 MustRunAs

注意

有关 pod 超时的更多信息,请参阅 BZ#1995779.

为避免 pod 超时,您可以创建一个自定义 SCC,并将 fsGroup.type 参数设置为 RunAsAny,并将它与自定义服务帐户关联。

注意

作为最佳实践,使用自定义 SCC 和自定义服务帐户来运行管道运行和任务运行。这种方法具有更大的灵活性,在升级过程中修改默认值时不会中断运行。

流程

  1. 定义自定义 SCC,并将 fsGroup.type 参数设置为 RunAsAny

    示例:自定义 SCC

    apiVersion: security.openshift.io/v1
    kind: SecurityContextConstraints
    metadata:
      annotations:
        kubernetes.io/description: my-scc is a close replica of anyuid scc. pipelines-scc has fsGroup - RunAsAny.
      name: my-scc
    allowHostDirVolumePlugin: false
    allowHostIPC: false
    allowHostNetwork: false
    allowHostPID: false
    allowHostPorts: false
    allowPrivilegeEscalation: true
    allowPrivilegedContainer: false
    allowedCapabilities: null
    defaultAddCapabilities: null
    fsGroup:
      type: RunAsAny
    groups:
    - system:cluster-admins
    priority: 10
    readOnlyRootFilesystem: false
    requiredDropCapabilities:
    - MKNOD
    runAsUser:
      type: RunAsAny
    seLinuxContext:
      type: MustRunAs
    supplementalGroups:
      type: RunAsAny
    volumes:
    - configMap
    - downwardAPI
    - emptyDir
    - persistentVolumeClaim
    - projected
    - secret
    Copy to Clipboard Toggle word wrap

  2. 创建自定义 SCC:

    示例:创建 my-scc SCC

    $ oc create -f my-scc.yaml
    Copy to Clipboard Toggle word wrap

  3. 创建自定义服务帐户:

    示例:创建一个 fsgroup-runasany 服务帐户

    $ oc create serviceaccount fsgroup-runasany
    Copy to Clipboard Toggle word wrap

  4. 将自定义 SCC 与自定义服务帐户关联:

    示例:将 my-scc SCC 与 fsgroup-runasany 服务帐户关联

    $ oc adm policy add-scc-to-user my-scc -z fsgroup-runasany
    Copy to Clipboard Toggle word wrap

    如果要将自定义服务帐户用于特权任务,您可以通过运行以下命令将 privileged SCC 与自定义服务帐户关联:

    示例:将 privileged SCC 与 fsgroup-runasany 服务帐户关联

    $ oc adm policy add-scc-to-user privileged -z fsgroup-runasany
    Copy to Clipboard Toggle word wrap

  5. 在管道运行和任务运行中使用自定义服务帐户:

    示例:Pipeline 使用 fsgroup-runasany 自定义服务帐户运行 YAML

    apiVersion: tekton.dev/v1beta1
    kind: PipelineRun
    metadata:
      name: <pipeline-run-name>
    spec:
      pipelineRef:
        name: <pipeline-cluster-task-name>
      serviceAccountName: 'fsgroup-runasany'
    Copy to Clipboard Toggle word wrap

    示例:任务使用 fsgroup-runasany 自定义服务帐户运行 YAML

    apiVersion: tekton.dev/v1beta1
    kind: TaskRun
    metadata:
      name: <task-run-name>
    spec:
      taskRef:
        name: <cluster-task-name>
      serviceAccountName: 'fsgroup-runasany'
    Copy to Clipboard Toggle word wrap

第 3 章 使用事件监听程序保护 Webhook

作为管理员,您可以使用事件监听程序保护 Webhook。创建命名空间后,您可以通过将 operator.tekton.dev/enable-annotation=enabled 标签添加到命名空间,为 Eventlistener 资源启用 HTTPS。然后,您可以使用重新加密的 TLS 终止创建 Trigger 资源和安全路由。

Red Hat OpenShift Pipelines 中的触发器支持不安全的 HTTP 和安全 HTTPS 连接到 Eventlistener 资源。HTTPS 保护集群内部和外部的连接。

Red Hat OpenShift Pipelines 运行 tekton-operator-proxy-webhook pod,用于监视命名空间中的标签。当您将标签添加到命名空间时,webhook 在 EventListener 对象上设置 service.beta.openshift.io/serving-cert-secret-name=<secret_name> 注解。这反过来会创建 secret 和所需的证书。

service.beta.openshift.io/serving-cert-secret-name=<secret_name>
Copy to Clipboard Toggle word wrap

另外,您可以将创建的 secret 挂载到 Eventlistener pod 中,以保护请求。

3.1. 提供与 OpenShift 路由的安全连接

要使用重新加密的 TLS 终止创建路由,请运行:

$ oc create route reencrypt --service=<svc-name> --cert=tls.crt --key=tls.key --ca-cert=ca.crt --hostname=<hostname>
Copy to Clipboard Toggle word wrap

或者,您可以创建一个重新加密的 TLS 终止 YAML 文件来创建安全路由。

重新加密 TLS 终止 YAML 示例,以创建安全路由

apiVersion: route.openshift.io/v1
kind: Route
metadata:
  name: route-passthrough-secured  
1

spec:
  host: <hostname>
  to:
    kind: Service
    name: frontend 
2

  tls:
    termination: reencrypt 
3

    key: [as in edge termination]
    certificate: [as in edge termination]
    caCertificate: [as in edge termination]
    destinationCACertificate: |- 
4

      -----BEGIN CERTIFICATE-----
      [...]
      -----END CERTIFICATE-----
Copy to Clipboard Toggle word wrap

1 2
对象的名称,仅限于 63 个字符。
3
termination 字段设置为 reencrypt。这是唯一需要的 TLS 字段。
4
这是重新加密所必需的。destinationCACertificate 字段指定一个 CA 证书来验证端点证书,从而保护从路由器到目的地 Pod 的连接。您可以在以下情况之一中省略此字段:
  • 服务使用服务签名证书。
  • 管理员为路由器指定默认 CA 证书,服务具有由该 CA 签名的证书。

您可以运行 oc create route reencrypt --help 命令显示更多选项。

本节使用 pipelines-tutorial 示例来演示使用安全 HTTPS 连接创建示例 EventListener 资源。

流程

  1. 从 pipelines-tutorial 存储库中的 YAML 文件创建 TriggerBinding 资源:

    $ oc create -f https://raw.githubusercontent.com/openshift/pipelines-tutorial/master/03_triggers/01_binding.yaml
    Copy to Clipboard Toggle word wrap
  2. 从 pipelines-tutorial 存储库中的 YAML 文件创建 TriggerTemplate 资源:

    $ oc create -f https://raw.githubusercontent.com/openshift/pipelines-tutorial/master/03_triggers/02_template.yaml
    Copy to Clipboard Toggle word wrap
  3. 直接从 pipelines-tutorial 存储库创建 Trigger 资源:

    $ oc create -f https://raw.githubusercontent.com/openshift/pipelines-tutorial/master/03_triggers/03_trigger.yaml
    Copy to Clipboard Toggle word wrap
  4. 使用安全 HTTPS 连接创建 EventListener 资源:

    1. 添加一个标签,在 Eventlistener 资源中启用安全 HTTPS 连接:

      $ oc label namespace <ns-name> operator.tekton.dev/enable-annotation=enabled
      Copy to Clipboard Toggle word wrap
    2. 从 pipelines-tutorial 存储库中的 YAML 文件创建 EventListener 资源:

      $ oc create -f https://raw.githubusercontent.com/openshift/pipelines-tutorial/master/03_triggers/04_event_listener.yaml
      Copy to Clipboard Toggle word wrap
    3. 创建带有重新加密 TLS 终止的路由:

      $ oc create route reencrypt --service=<svc-name> --cert=tls.crt --key=tls.key --ca-cert=ca.crt --hostname=<hostname>
      Copy to Clipboard Toggle word wrap

第 4 章 使用 git secret 验证管道

Git 机密由凭据组成,可以安全地与 Git 存储库交互,通常用于自动执行身份验证。在 Red Hat OpenShift Pipelines 中,您可以使用 Git secret 验证管道运行和在执行过程中与 Git 存储库交互的任务运行。

管道运行或任务运行通过关联的服务帐户获取对 secret 的访问权限。OpenShift Pipelines 支持将 Git secret 用作基于基本身份验证和基于 SSH 的身份验证的注解(键值对)。

4.1. 凭证选择

管道运行或任务运行可能需要多次身份验证才能访问不同的 Git 存储库。使用 OpenShift Pipelines 可以使用其凭证的域注解每个 secret。

Git secret 的凭证注解键必须以 tekton.dev/git- 开头,其值是您要 OpenShift Pipelines 使用该凭证的主机的 URL。

在以下示例中,OpenShift Pipelines 使用 basic-auth secret (依赖于用户名和密码)访问位于 github.comgitlab.com 的存储库。

示例:用于基本身份验证的多个凭证

apiVersion: v1
kind: Secret
metadata:
  annotations:
    tekton.dev/git-0: github.com
    tekton.dev/git-1: gitlab.com
type: kubernetes.io/basic-auth
stringData:
  username: <username> 
1

  password: <password> 
2
Copy to Clipboard Toggle word wrap

1
软件仓库的用户名
2
存储库的密码或个人访问令牌

您还可以使用 ssh-auth secret(私钥)来访问 Git 存储库。

示例:用于基于 SSH 的身份验证的私钥

apiVersion: v1
kind: Secret
metadata:
  annotations:
    tekton.dev/git-0: https://github.com
type: kubernetes.io/ssh-auth
stringData:
  ssh-privatekey: 
1
Copy to Clipboard Toggle word wrap

1
SSH 私钥文件的内容。

4.2. 为 Git 配置基本身份验证

管道若要从密码保护的存储库检索资源,您必须为该管道配置基本身份验证。

要为管道配置基本身份验证,请使用指定存储库的 Git secret 中的凭证更新 secret.yamlserviceaccount.yamlrun.yaml 文件。完成此过程后,OpenShift Pipelines 可使用该信息来检索指定的管道资源。

注意

对于 GitHub,已弃用使用普通密码进行身份验证。而应使用个人访问令牌

流程

  1. secret.yaml 文件中,指定用户名和密码或 GitHub 个人访问令牌来访问目标 Git 存储库。

    apiVersion: v1
    kind: Secret
    metadata:
      name: basic-user-pass 
    1
    
      annotations:
        tekton.dev/git-0: https://github.com
    type: kubernetes.io/basic-auth
    stringData:
      username: <username> 
    2
    
      password: <password> 
    3
    Copy to Clipboard Toggle word wrap
    1
    secret 的名称。在本例中,basic-user-pass
    2
    Git 存储库的用户名。
    3
    Git 存储库的密码。
  2. serviceaccount.yaml 文件中,将 secret 与适当的服务帐户关联。

    apiVersion: v1
    kind: ServiceAccount
    metadata:
      name: build-bot 
    1
    
    secrets:
      - name: basic-user-pass 
    2
    Copy to Clipboard Toggle word wrap
    1
    服务帐户的名称。在本例中,build-bot
    2
    secret 的名称。在本例中,basic-user-pass
  3. run.yaml 文件中,将服务帐户与任务运行或管道运行关联。

    • 将服务帐户与任务运行关联:

      apiVersion: tekton.dev/v1beta1
      kind: TaskRun
      metadata:
        name: build-push-task-run-2 
      1
      
      spec:
        serviceAccountName: build-bot 
      2
      
        taskRef:
          name: build-push 
      3
      Copy to Clipboard Toggle word wrap
      1
      任务运行的名称。在本例中,build-push-task-run-2
      2
      服务帐户的名称。在本例中,build-bot
      3
      任务的名称。在本例中,build-push
    • 将服务帐户与 PipelineRun 资源关联:

      apiVersion: tekton.dev/v1beta1
      kind: PipelineRun
      metadata:
        name: demo-pipeline 
      1
      
        namespace: default
      spec:
        serviceAccountName: build-bot 
      2
      
        pipelineRef:
          name: demo-pipeline 
      3
      Copy to Clipboard Toggle word wrap
      1
      管道运行的名称。在本例中,demo-pipeline
      2
      服务帐户的名称。在本例中,build-bot
      3
      管道的名称。在本例中,demo-pipeline
  4. 应用更改。

    $ oc apply --filename secret.yaml,serviceaccount.yaml,run.yaml
    Copy to Clipboard Toggle word wrap

4.3. 为 Git 配置 SSH 身份验证

若要让管道从配置了 SSH 密钥的存储库检索资源,您必须为该管道配置基于 SSH 的身份验证。

要为管道配置基于 SSH 的身份验证,请使用指定存储库的 SSH 私钥中的凭证更新 secret.yamlserviceaccount.yamlrun.yaml 文件。完成此过程后,OpenShift Pipelines 可使用该信息来检索指定的管道资源。

注意

考虑使用基于 SSH 的身份验证而不是基本身份验证。

流程

  1. 生成 SSH 私钥,或复制通常在 ~/.ssh/id_rsa 文件中提供的现有私钥。
  2. secret.yaml 文件中,将 ssh-privatekey 的值设置为 SSH 私钥文件的内容,并将 known_hosts 的值设置为已知主机文件的内容。

    apiVersion: v1
    kind: Secret
    metadata:
      name: ssh-key 
    1
    
      annotations:
        tekton.dev/git-0: github.com
    type: kubernetes.io/ssh-auth
    stringData:
      ssh-privatekey: 
    2
    
      known_hosts: 
    3
    Copy to Clipboard Toggle word wrap
    1
    包含 SSH 私钥的机密的名称。在本例中,ssh-key
    2
    SSH 私钥文件的内容。
    3
    已知主机文件的内容。
    Important

    如果省略私钥,OpenShift Pipelines 会接受任何服务器的公钥。

  3. 可选: 要指定一个自定义 SSH 端口,请在 annotation 值的末尾添加 :<port number>.例如: tekton.dev/git-0: github.com:2222
  4. serviceaccount.yaml 文件中,将 ssh-key secret 与 build-bot 服务帐户关联。

    apiVersion: v1
    kind: ServiceAccount
    metadata:
      name: build-bot 
    1
    
    secrets:
      - name: ssh-key 
    2
    Copy to Clipboard Toggle word wrap
    1
    服务帐户的名称。在本例中,build-bot
    2
    包含 SSH 私钥的机密的名称。在本例中,ssh-key
  5. run.yaml 文件中,将服务帐户与任务运行或管道运行关联。

    • 将服务帐户与任务运行关联:

      apiVersion: tekton.dev/v1beta1
      kind: TaskRun
      metadata:
        name: build-push-task-run-2 
      1
      
      spec:
        serviceAccountName: build-bot 
      2
      
        taskRef:
          name: build-push 
      3
      Copy to Clipboard Toggle word wrap
      1
      任务运行的名称。在本例中,build-push-task-run-2
      2
      服务帐户的名称。在本例中,build-bot
      3
      任务的名称。在本例中,build-push
    • 将服务帐户与管道运行关联:

      apiVersion: tekton.dev/v1beta1
      kind: PipelineRun
      metadata:
        name: demo-pipeline 
      1
      
        namespace: default
      spec:
        serviceAccountName: build-bot 
      2
      
        pipelineRef:
          name: demo-pipeline 
      3
      Copy to Clipboard Toggle word wrap
      1
      管道运行的名称。在本例中,demo-pipeline
      2
      服务帐户的名称。在本例中,build-bot
      3
      管道的名称。在本例中,demo-pipeline
  6. 应用更改。

    $ oc apply --filename secret.yaml,serviceaccount.yaml,run.yaml
    Copy to Clipboard Toggle word wrap

4.4. 在 git 类型任务中使用 SSH 身份验证

在调用 Git 命令时,您可以在任务的步骤中直接使用 SSH 身份验证。SSH 身份验证忽略 $HOME 变量,并且仅使用 /etc/passwd 文件中指定的用户主目录。因此,任务中的每个步骤都必须将 /tekton/home/.ssh 目录符号链接到相关用户的主目录。

但是,当您使用 git 类型的管道资源或 Tekton 目录中提供的 git-clone 任务时,不需要显式符号链接。

有关在 git 类型任务中使用 SSH 身份验证的示例,请参阅 authenticating-git-commands.yaml

4.5. 以非 root 用户身份使用 secret

在某些情况下,您可能需要将 secret 用作非 root 用户,例如:

  • 容器用于执行运行的用户和组由平台随机化。
  • 任务中的步骤定义非 root 安全性上下文。
  • 任务指定一个全局非 root 安全上下文,它应用到任务中的所有步骤。

在这种情况下,请考虑以非 root 用户身份运行任务和管道运行的以下方面:

  • Git 的 SSH 身份验证要求用户在 /etc/passwd 目录中配置有效的主目录。指定没有有效主目录的 UID 会导致身份验证失败。
  • SSH 身份验证会忽略 $HOME 环境变量。因此,您必须将 OpenShift Pipelines 定义的 $HOME 目录(/tekton/home)中的 secret 文件符号链接到非 root 用户的有效主目录。

此外,若要在非 root 安全上下文中配置 SSH 身份验证,请参阅对 git 命令进行身份验证的示例

4.6. 限制对特定步骤的 secret 访问

默认情况下,OpenShift Pipelines 的 secret 存储在 $HOME/tekton/home 目录中,并可用于任务中的所有步骤。

要将 secret 限制为特定的步骤,请使用 secret 定义指定卷,并在特定步骤中挂载卷。

作为 root 用户在容器上运行 OpenShift Pipelines,可以将容器进程和主机公开给其他潜在的恶意资源。您可以作为容器中的特定非 root 用户运行工作负载来降低此类风险。要以非 root 用户身份使用 Buildah 运行容器镜像的构建,可以执行以下步骤:

  • 定义自定义服务帐户 (SA) 和安全性上下文约束 (SCC)。
  • 配置 Buildah,以使用 ID 为 1000build 用户。
  • 使用自定义配置映射启动任务运行,或将其与管道运行集成。

5.1. 配置自定义服务帐户和安全上下文约束

默认 pipeline SA 允许使用命名空间范围之外的用户 ID。要减少对默认 SA 的依赖性,您可以为 ID 为 1000build 用户定义具有必要的集群角色和角色绑定的自定义 SA 和 SCC。

重要

目前,Buildah 需要启用 allowPrivilegeEscalation 设置,才能在容器中运行。通过这个设置,Buildah 可以在以非 root 用户身份运行时利用 SETUIDSETGID 功能。

流程

  • 使用必要的集群角色和角色绑定创建自定义 SA 和 SCC。

    示例:用户 id 为 1000 的自定义 SA 和 SCC。

    apiVersion: v1
    kind: ServiceAccount
    metadata:
      name: pipelines-sa-userid-1000 
    1
    
    ---
    kind: SecurityContextConstraints
    metadata:
      annotations:
      name: pipelines-scc-userid-1000 
    2
    
    allowHostDirVolumePlugin: false
    allowHostIPC: false
    allowHostNetwork: false
    allowHostPID: false
    allowHostPorts: false
    allowPrivilegeEscalation: true 
    3
    
    allowPrivilegedContainer: false
    allowedCapabilities: null
    apiVersion: security.openshift.io/v1
    defaultAddCapabilities: null
    fsGroup:
      type: MustRunAs
    groups:
    - system:cluster-admins
    priority: 10
    readOnlyRootFilesystem: false
    requiredDropCapabilities:
    - MKNOD
    - KILL
    runAsUser: 
    4
    
      type: MustRunAs
      uid: 1000
    seLinuxContext:
      type: MustRunAs
    supplementalGroups:
      type: RunAsAny
    users: []
    volumes:
    - configMap
    - downwardAPI
    - emptyDir
    - persistentVolumeClaim
    - projected
    - secret
    ---
    apiVersion: rbac.authorization.k8s.io/v1
    kind: ClusterRole
    metadata:
      name: pipelines-scc-userid-1000-clusterrole 
    5
    
    rules:
    - apiGroups:
      - security.openshift.io
      resourceNames:
      - pipelines-scc-userid-1000
      resources:
      - securitycontextconstraints
      verbs:
      - use
    ---
    apiVersion: rbac.authorization.k8s.io/v1
    kind: RoleBinding
    metadata:
      name: pipelines-scc-userid-1000-rolebinding 
    6
    
    roleRef:
      apiGroup: rbac.authorization.k8s.io
      kind: ClusterRole
      name: pipelines-scc-userid-1000-clusterrole
    subjects:
    - kind: ServiceAccount
      name: pipelines-sa-userid-1000
    Copy to Clipboard Toggle word wrap

1
定义一个自定义 SA。
2
使用修改的 runAsUser 字段,定义基于受限特权创建的自定义 SCC。
3
目前,Buildah 需要启用 allowPrivilegeEscalation 设置,才能在容器中运行。通过这个设置,Buildah 可以在以非 root 用户身份运行时利用 SETUIDSETGID 功能。
4
限制通过自定义 SA 附加了自定义 SCC 的 Pod,使其以用户 ID 1000 身份运行。
5
定义使用自定义 SCC 的集群角色。
6
将使用自定义 SCC 的集群角色绑定到自定义 SA。

5.2. 配置 Buildah 以使用 build 用户

您可以定义一个 Buildah 任务,以使用带有用户 ID 1000build 用户。

流程

  1. 作为普通任务,创建 buildah 集群任务的副本。

    $ oc get clustertask buildah -o yaml | yq '. |= (del .metadata |= with_entries(select(.key == "name" )))' | yq '.kind="Task"' | yq '.metadata.name="buildah-as-user"' | oc create -f -
    Copy to Clipboard Toggle word wrap
  2. 编辑复制的 buildah 任务。

    $ oc edit task buildah-as-user
    Copy to Clipboard Toggle word wrap

    示例:使用 build 用户修改 Buildah 任务

    apiVersion: tekton.dev/v1beta1
    kind: Task
    metadata:
      name: buildah-as-user
    spec:
      description: >-
        Buildah task builds source into a container image and
        then pushes it to a container registry.
        Buildah Task builds source into a container image using Project Atomic's
        Buildah build tool.It uses Buildah's support for building from Dockerfiles,
        using its buildah bud command.This command executes the directives in the
        Dockerfile to assemble a container image, then pushes that image to a
        container registry.
      params:
      - name: IMAGE
        description: Reference of the image buildah will produce.
      - name: BUILDER_IMAGE
        description: The location of the buildah builder image.
        default: registry.redhat.io/rhel8/buildah@sha256:99cae35f40c7ec050fed3765b2b27e0b8bbea2aa2da7c16408e2ca13c60ff8ee
      - name: STORAGE_DRIVER
        description: Set buildah storage driver
        default: vfs
      - name: DOCKERFILE
        description: Path to the Dockerfile to build.
        default: ./Dockerfile
      - name: CONTEXT
        description: Path to the directory to use as context.
        default: .
      - name: TLSVERIFY
        description: Verify the TLS on the registry endpoint (for push/pull to a non-TLS registry)
        default: "true"
      - name: FORMAT
        description: The format of the built container, oci or docker
        default: "oci"
      - name: BUILD_EXTRA_ARGS
        description: Extra parameters passed for the build command when building images.
        default: ""
      - description: Extra parameters passed for the push command when pushing images.
        name: PUSH_EXTRA_ARGS
        type: string
        default: ""
      - description: Skip pushing the built image
        name: SKIP_PUSH
        type: string
        default: "false"
      results:
      - description: Digest of the image just built.
        name: IMAGE_DIGEST
        type: string
      workspaces:
      - name: source
      steps:
      - name: build
        securityContext:
          runAsUser: 1000 
    1
    
        image: $(params.BUILDER_IMAGE)
        workingDir: $(workspaces.source.path)
        script: |
          echo "Running as USER ID `id`" 
    2
    
          buildah --storage-driver=$(params.STORAGE_DRIVER) bud \
            $(params.BUILD_EXTRA_ARGS) --format=$(params.FORMAT) \
            --tls-verify=$(params.TLSVERIFY) --no-cache \
            -f $(params.DOCKERFILE) -t $(params.IMAGE) $(params.CONTEXT)
          [[ "$(params.SKIP_PUSH)" == "true" ]] && echo "Push skipped" && exit 0
          buildah --storage-driver=$(params.STORAGE_DRIVER) push \
            $(params.PUSH_EXTRA_ARGS) --tls-verify=$(params.TLSVERIFY) \
            --digestfile $(workspaces.source.path)/image-digest $(params.IMAGE) \
            docker://$(params.IMAGE)
          cat $(workspaces.source.path)/image-digest | tee /tekton/results/IMAGE_DIGEST
        volumeMounts:
        - name: varlibcontainers
          mountPath: /home/build/.local/share/containers 
    3
    
      volumes:
      - name: varlibcontainers
        emptyDir: {}
    Copy to Clipboard Toggle word wrap

    1
    以用户 id 1000 明确运行容器,它与 Buildah 镜像中的 build 用户对应。
    2
    显示用户 id,以确认进程以用户 ID 1000 身份运行。
    3
    您可以根据需要更改卷挂载的路径。

定义自定义 Buildah 集群任务后,您可以创建一个 TaskRun 对象,该对象以 build 用户,使用用户 id 1000 来构建镜像。另外,您还可以将 TaskRun 对象集成为 PipelineRun 对象的一部分。

流程

  1. 使用自定义 ConfigMapDockerfile 对象创建一个 TaskRun 对象。

    示例:以用户 ID 1000 身份运行 Buildah 的任务运行

    apiVersion: v1
    data:
      Dockerfile: |
        ARG BASE_IMG=registry.access.redhat.com/ubi8/ubi
        FROM $BASE_IMG AS buildah-runner
        RUN dnf -y update && \
            dnf -y install git && \
            dnf clean all
        CMD git
    kind: ConfigMap
    metadata:
      name: dockerfile 
    1
    
    ---
    apiVersion: tekton.dev/v1beta1
    kind: TaskRun
    metadata:
      name: buildah-as-user-1000
    spec:
      serviceAccountName: pipelines-sa-userid-1000 
    2
    
      params:
      - name: IMAGE
        value: image-registry.openshift-image-registry.svc:5000/test/buildahuser
      taskRef:
        kind: Task
        name: buildah-as-user
      workspaces:
      - configMap:
          name: dockerfile 
    3
    
        name: source
    Copy to Clipboard Toggle word wrap

    1
    使用配置映射,因为重点是在任务运行中,而无需使用 Dockerfile 获取某些源的以前的任务。
    2
    您创建的服务帐户的名称。
    3
    将配置映射挂载为 buildah-as-user 任务的源工作区。
  2. (可选)创建管道和对应的管道运行。

    示例:管道和对应的管道运行

    apiVersion: tekton.dev/v1beta1
    kind: Pipeline
    metadata:
      name: pipeline-buildah-as-user-1000
    spec:
      params:
      - name: IMAGE
      - name: URL
      workspaces:
      - name: shared-workspace
      - name: sslcertdir
        optional: true
      tasks:
      - name: fetch-repository 
    1
    
        taskRef:
          name: git-clone
          kind: ClusterTask
        workspaces:
        - name: output
          workspace: shared-workspace
        params:
        - name: url
          value: $(params.URL)
        - name: subdirectory
          value: ""
        - name: deleteExisting
          value: "true"
      - name: buildah
        taskRef:
          name: buildah-as-user 
    2
    
        runAfter:
        - fetch-repository
        workspaces:
        - name: source
          workspace: shared-workspace
        - name: sslcertdir
          workspace: sslcertdir
        params:
        - name: IMAGE
          value: $(params.IMAGE)
    ---
    apiVersion: tekton.dev/v1beta1
    kind: PipelineRun
    metadata:
      name: pipelinerun-buildah-as-user-1000
    spec:
      taskRunSpecs:
        - pipelineTaskName: buildah
          taskServiceAccountName: pipelines-sa-userid-1000 
    3
    
      params:
      - name: URL
        value: https://github.com/openshift/pipelines-vote-api
      - name: IMAGE
        value: image-registry.openshift-image-registry.svc:5000/test/buildahuser
      pipelineRef:
        name: pipeline-buildah-as-user-1000
      workspaces:
      - name: shared-workspace 
    4
    
        volumeClaimTemplate:
          spec:
            accessModes:
              - ReadWriteOnce
            resources:
              requests:
                storage: 100Mi
    Copy to Clipboard Toggle word wrap

    1
    使用 git-clone 集群任务获取包含 Dockerfile 的源,并使用修改后的 Buildah 任务构建它。
    2
    请参阅修改后的 Buildah 任务。
    3
    使用您为 Buildah 任务创建的服务帐户。
    4
    使用控制器自动创建的持久性卷声明 (PVC) 在 git-clone 任务和修改后的 Buildah 任务间共享数据。
  3. 启动任务运行或管道运行。

5.4. 无特权构建的限制

无特权构建的进程可用于大多数 Dockerfile 对象。但是,一些已知的限制可能会导致构建失败:

  • 由于缺少必要权限问题,使用 --mount=type=cache 选项可能会失败。如需更多信息,请参阅本文档
  • 使用 --mount=type=secret 选项会失败,因为挂载资源需要未由自定义 SCC 提供的额外功能。

法律通告

Copyright © 2023 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