OpenShift 文档正在迁移，很快将只在 docs.redhat.com（所有 Red Hat 产品文档的中心）提供。立即体验 新的文档体验。
  1. 文档
    2. history bug_report picture_as_pdf
×

服务传输加密

您可以启用 OpenShift Serverless Serving 传输加密，以允许使用 TLS 通过安全且加密的 HTTPS 连接传输数据。

OpenShift Serverless Serving 传输加密仅为技术预览功能。技术预览功能不受 Red Hat 生产服务级别协议 (SLA) 支持，并且可能功能不完整。Red Hat 不建议在生产环境中使用它们。这些功能提供对即将推出的产品功能的早期访问，使客户能够在开发过程中测试功能并提供反馈。

有关 Red Hat 技术预览功能的支持范围的更多信息，请参阅技术预览功能支持范围。

Serving 传输加密仅对 Kourier 作为入口层可用。对于 Red Hat OpenShift Service Mesh，请使用服务网格 mTLS 功能来确保加密流量。

Serving 传输加密概述

OpenShift Serverless Serving 传输加密分为三个部分

外部域加密

集群外部入口层的传输加密。例如，集群外部域，例如 `myapp-<namespace>.example.com`。

集群本地加密

集群内部入口层的传输加密。例如，集群本地域，例如 `myapp.<namespace>.svc.cluster.local`。

系统内部加密

ingress-gateway、activator 和 queue-proxy Knative 内部组件之间的传输加密。

控制平面流量（包括 Kubernetes PreStopHooks、元数据和指标）不包含用户数据，也不加密。

这些部分彼此独立，可以单独启用和禁用。它们可以使用相同或不同的证书颁发机构 (CA) 来签署必要的证书。

有关说明传输加密的图表，请参阅OpenShift Serverless Serving 传输加密。

外部域加密

外部域的传输加密由集群的入口层处理，该入口层是 OpenShift Container Platform 入口或 Red Hat OpenShift Service Mesh。

集群本地加密

集群本地加密启用集群本地域的传输加密。它具有以下属性

  • 证书通用名称 (CN) 或主题替代名称 (SAN) 包含 Knative 服务的集群本地域，例如 `myapp.namespace.svc.cluster.local`、`myapp.namespace.svc`、`myapp.namespace`。

  • ingress-controller 组件的集群本地端点使用 SNI 来选择证书。

  • 为了创建证书，Knative 依赖于cert-manager，需要安装并配置此组件才能启用该功能。更多信息，请参见 Red Hat OpenShift 的 cert-manager 运算符。

调用方必须信任签署集群本地证书的 CA。这不在 OpenShift Serverless 的范围内。

系统内部加密

系统内部加密为 Knative 内部组件ingress-gateway、activator 和queue-proxy启用传输加密。使用此配置时，这些组件将托管 TLS 终结点。

要使用此功能，必须满足以下先决条件：

  • 为了让 OpenShift Serverless 获取证书，必须安装并配置cert-manager。

  • 使用特定的 SAN 来验证每个连接。每个组件都必须信任签署证书的 CA。为了满足此要求，OpenShift Serverless 系统组件使用并信任一组 CA。CA 捆绑包必须由集群管理员提供。

证书颁发机构的选择

颁发机构指的是cert-manager颁发机构和集群颁发机构。它们代表可以根据证书签名请求生成已签名证书的证书颁发机构 (CA)。更多信息，请参见 cert-manager 关于颁发机构的文档。

根据您使用的加密功能，OpenShift Serverless 需要您的证书颁发机构能够签署某些证书。要识别您的证书颁发机构，请参考 cert-manager 集成列表，其中包含以下示例：

  • 存储在 Kubernetes 密钥中的自定义 CA

  • HTTP-01 挑战

  • DNS-01 挑战

  • 自签名颁发机构

兼容的证书颁发机构

并非所有颁发机构类型都适用于每个 Knative Serving 加密功能。

  • 对于集群本地加密，颁发机构必须能够为以下集群本地域名类型签署证书：

    • myapp.<namespace>

    • myapp.<namespace>.svc

    • myapp.<namespace>.svc.cluster.local

    由于 CA 通常不在集群内，因此无法使用自动证书管理环境 (ACME) 协议 (DNS01/HTTP01) 进行验证。您可以使用允许创建这些证书的颁发机构，例如cert-manager CA 颁发机构。

  • 对于系统内部加密，颁发机构必须能够使用以下主题备用名称 (SAN) 签署证书：

    • kn-routing

    • 格式为kn-user-<namespace>的名称，其中<namespace>是创建 Knative 服务的命名空间。

    • data-plane.knative.dev

    Knative 需要这些 SAN 来验证内部组件之间的连接。由于无法使用 ACME 协议 (DNS01/HTTP01)，您必须配置允许创建这些证书的颁发机构，例如cert-manager CA 颁发机构。

设置 OpenShift Serverless 传输加密

先决条件

  • 您可以访问具有集群管理员访问权限的 OpenShift Container Platform 帐户。

  • 安装 {oc-first}。

  • 安装 Red Hat OpenShift 的 cert-manager 运算符。

  • 安装 OpenShift Serverless 运算符。

如果您在安装 Red Hat OpenShift 的 cert-manager 运算符之前安装了 OpenShift Serverless 运算符，则必须重新启动knative-serving命名空间中的控制器和激活器部署。如果未能重新启动这些部署，则会阻止 Knative 创建必要的cert-manager资源，从而导致 Knative 服务处于挂起状态，并阻止启用 Knative Serving cert-manager集成。

配置 SelfSigned 集群颁发机构

以下步骤使用SelfSigned颁发机构作为根证书。有关此方法的含义和限制的信息，请参见 SelfSigned cert-manager 文档。

如果您管理您自己的公司专用私钥基础设施 (PKI)，请使用 CA 颁发机构。更多信息，请参见 cert-manager 关于 CA 颁发机构的文档。

步骤

  1. 创建一个SelfSigned ClusterIssuer 自定义资源 (CR)

    ClusterIssuer CR 示例
    apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
  name: knative-serving-selfsigned-issuer
spec:
  selfSigned: {}

  2. 通过运行以下命令应用ClusterIssuer CR

    $ oc apply -f <filename>

  3. 创建一个引用ClusterIssuer CR 的根证书

    根证书示例
    apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: knative-serving-selfsigned-ca
  namespace: cert-manager (1)
spec:
  secretName: knative-serving-ca (2)

  isCA: true
  commonName: selfsigned-ca
  privateKey:
    algorithm: ECDSA
    size: 256

  issuerRef:
    name: knative-serving-selfsigned-issuer
    kind: ClusterIssuer
    group: cert-manager.io
    1 Red Hat OpenShift 的 cert-manager 运算符命名空间，默认为cert-manager。
    2 稍后用于 Knative Serving 的ClusterIssuer CR 的密钥名称。

  4. 通过运行以下命令应用Certificate CR

    $ oc apply -f <filename>

创建 Serving 将使用的 ClusterIssuer

要启用 Serving 使用证书，必须创建一个集群颁发机构。

步骤

  1. 为 Serving 创建knative-serving-ca-issuer ClusterIssuer

    apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
  name: knative-serving-ca-issuer
spec:
  ca:
    secretName: knative-serving-ca (1)
    1 Red Hat OpenShift 的 cert-manager 运算符命名空间 (默认为cert-manager) 中的密钥名称，其中包含 OpenShift Serverless Serving 组件可用于新证书的证书。

  2. 通过运行以下命令应用ClusterIssuer资源

    $ oc apply -f <filename>

配置传输加密

配置传输加密包括两个部分：

  1. 指定要使用的ClusterIssuer颁发机构

    • clusterLocalIssuerRef：用于入口的集群本地域名证书的颁发机构。

    • systemInternalIssuerRef：Knative 内部组件使用的系统内部 tls 证书的颁发机构。

  2. 指定要使用的传输加密功能

    • cluster-local-domain-tls：启用集群本地域的传输加密功能

    • system-internal-tls：启用 OpenShift Serverless Serving 内部组件的传输加密功能。

步骤

  1. 在KnativeServing资源中启用传输加密

    apiVersion: operator.knative.dev/v1beta1
kind: KnativeServing
metadata:
  name: knative-serving
  namespace: knative-serving
spec:
  ...
  config:
    certmanager:
      clusterLocalIssuerRef: |
        kind: ClusterIssuer
        name: knative-serving-ca-issuer (1)
      systemInternalIssuerRef: |
        kind: ClusterIssuer
        name: knative-serving-ca-issuer (2)
    network:
      cluster-local-domain-tls: Enabled (3)
      system-internal-tls: Enabled (4)
    1 为每个功能定义集群颁发机构。可以使用相同或单独的集群颁发机构。
    2 定义集群颁发机构。
    3 启用cluster-local-domain-tls功能。此功能和其他功能可以单独启用或禁用。
    4 启用system-internal-tls功能。

  2. 通过运行以下命令应用KnativeServing资源

    $ oc apply -f <filename>

  3. 可选：更改 Ingress Controller 中的defaultCertificate值

    apiVersion: operator.openshift.io/v1
kind: IngressController
 ...
spec:
  defaultCertificate:
    name: ca-ingress-cert

  4. 如果更改了defaultCertificate值，则必须在KnativeServing自定义资源中的openshift-ingress-default-certificate字段中指定自定义证书名称。

    例如，如果自定义证书名称为ca-ingress-cert，请添加以下配置

    ...
spec:
  config:
    network:
      system-internal-tls: Enabled
      openshift-ingress-default-certificate: "ca-ingress-cert"
...

  5. 如果您启用了cluster-local-domain-tls或system-internal-tls，请运行以下命令重启 Controller 组件。

    启用cluster-local-domain-tls或system-internal-tls功能后，必须重启 Controller 组件才能启用 Knative Serving cert-manager 集成。

    		 
    $ oc rollout restart deploy/controller -n knative-serving

  6. 如果您启用了system-internal-tls，请运行以下命令重启 Activator 组件。

    激活system-internal-tls功能后，必须重启 Activator 组件以重新配置其内部 Web 服务器，因为这在运行时无法完成。

    		 
    $ oc rollout restart deploy/activator -n knative-serving

信任配置

启用任何传输加密功能时，必须确保所有调用客户端都信任为传输加密颁发证书的证书颁发机构 (CA)。

必须确保多个位置的信任

  • 集群外部客户端，例如浏览器或其他应用程序。这不在 OpenShift Serverless 的范围内。

  • OpenShift Serverless 系统组件，例如 Activator、Queue-Proxy 和 Ingress-Controller。

  • 集群内部客户端，例如 Knative 服务或其他工作负载。

OpenShift Serverless Serving 组件和 Knative 服务的信任配置

为了确保 OpenShift Serverless Serving 组件和 Knative 服务信任颁发证书的 CA，您可以在以下命名空间中创建带有标签networking.knative.dev/trust-bundle: true的 ConfigMap

knative-serving

用于 OpenShift Serverless Serving 的系统组件。

knative-serving-ingress

用于 OpenShift Serverless Serving 的 Ingress 层。

istio-system 或您自己的 Service Mesh 命名空间

启用 Service Mesh 集成时。

Knative 读取带有此标签的所有 ConfigMap 中的所有数据键，而不管名称如何。一个键可以包含一个或多个 CA 或中间证书。如果它们有效，则会将它们添加到 Knative 组件的信任存储中。

这是一个 ConfigMap 示例

apiVersion: v1
data:
  cacerts.pem: | (1)
    -----BEGIN CERTIFICATE-----
    MIIDDTCCAfWgAwIBAgIQMQuip05h7NLQq2TB+j9ZmTANBgkqhkiG9w0BAQsFADAW
    MRQwEgYDVQQDEwtrbmF0aXZlLmRldjAeFw0yMzExMjIwOTAwNDhaFw0yNDAyMjAw
    OTAwNDhaMBYxFDASBgNVBAMTC2tuYXRpdmUuZGV2MIIBIjANBgkqhkiG9w0BAQEF
    AAOCAQ8AMIIBCgKCAQEA3clC3CV7sy0TpUKNuTku6QmP9z8JUCbLCPCLACCUc1zG
    FEokqOva6TakgvAntXLkB3TEsbdCJlNm6qFbbko6DBfX6rEggqZs40x3/T+KH66u
    4PvMT3fzEtaMJDK/KQOBIvVHrKmPkvccUYK/qWY7rgBjVjjLVSJrCn4dKaEZ2JNr
    Fd0KNnaaW/dP9/FvviLqVJvHnTMHH5qyRRr1kUGTrc8njRKwpHcnUdauiDoWRKxo
    Zlyy+MhQfdbbyapX984WsDjCvrDXzkdGgbRNAf+erl6yUm6pHpQhyFFo/zndx6Uq
    QXA7jYvM2M3qCnXmaFowidoLDsDyhwoxD7WT8zur/QIDAQABo1cwVTAOBgNVHQ8B
    Af8EBAMCAgQwEwYDVR0lBAwwCgYIKwYBBQUHAwEwDwYDVR0TAQH/BAUwAwEB/zAd
    BgNVHQ4EFgQU7p4VuECNOcnrP9ulOjc4J37Q2VUwDQYJKoZIhvcNAQELBQADggEB
    AAv26Vnk+ptQrppouF7yHV8fZbfnehpm07HIZkmnXO2vAP+MZJDNrHjy8JAVzXjt
    +OlzqAL0cRQLsUptB0btoJuw23eq8RXgJo05OLOPQ2iGNbAATQh2kLwBWd/CMg+V
    KJ4EIEpF4dmwOohsNR6xa/JoArIYH0D7gh2CwjrdGZr/tq1eMSL+uZcuX5OiE44A
    2oXF9/jsqerOcH7QUMejSnB8N7X0LmUvH4jAesQgr7jo1JTOBs7GF6wb+U76NzFa
    8ms2iAWhoplQ+EHR52wffWb0k6trXspq4O6v/J+nq9Ky3vC36so+G1ZFkMhCdTVJ
    ZmrBsSMWeT2l07qeei2UFRU=
    -----END CERTIFICATE-----
kind: ConfigMap
metadata:
  labels:
    networking.knative.dev/trust-bundle: "true"
  name: knative-bundle (2)
  namespace: knative-serving
1 Serving 组件信任包含有效 PEM 编码 CA 捆绑包的所有键。
2 您可以使用任意名称。

创建或更新 CA 捆绑包 ConfigMap 时，Serving 组件会自动获取它们并将 CA 或中间证书添加到它们的 CA 信任存储中。对于每个新的 HTTP 连接，都会刷新信任存储。

自定义工作负载上的信任配置

由于 OpenShift Serverless Serving 并不控制所有工作负载，并且管理信任高度依赖于您的运行时和语言，因此自定义工作负载不在 OpenShift Serverless 的范围内。以下是自定义工作负载的其他选项

  • 在构建时将 CA 捆绑包添加到容器镜像。请注意，这会使 CA 轮换变得复杂，因为在 CA 轮换时，您必须重新构建和重新部署每个应用程序。

  • 将 CA 捆绑包挂载到文件系统，例如从 Secret 或 ConfigMap 挂载，并确保您的应用程序使用它来验证 TLS 连接。

  • 从环境变量读取 CA 捆绑包，并确保您的应用程序使用它来验证 TLS 连接。

  • 使用 Kubernetes API 从 Secret 或 ConfigMap 访问 CA 捆绑包，并确保您的应用程序使用它来验证 TLS 连接。

确保无缝 CA 轮换

确保无缝 CA 轮换对于避免服务停机或处理紧急情况至关重要。

步骤

  1. 创建新的 CA 证书。

  2. 将新 CA 证书的公钥添加到 CA 信任捆绑包中，如“OpenShift Serverless Operator Serving 组件和 Knative 服务的信任配置”部分所述。保留现有 CA 的公钥。

  3. 确保所有客户端都已使用最新的 CA 信任捆绑包集。OpenShift Serverless Serving 组件将自动重新加载已更改的 CA 信任捆绑包。

  4. 如果您有使用信任捆绑包的自定义工作负载，请相应地重新加载或重启它们。

  5. 更新knative-serving-ca-issuer集群颁发者以引用包含新 CA 证书的密钥。

  6. 等待cert-manager更新所有证书，或强制其更新所有证书。有关更多信息，请参阅cert-manager文档。

  7. CA 轮换完全完成后，您可以从信任捆绑包 configmap 中删除旧 CA 的公钥。留出足够的时间让所有组件应用更改。

其他资源

验证已启用传输加密

步骤

  1. 创建一个 Knative 服务

    apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: test-webapp
  namespace: test-namespace
spec:
  template:
    spec:
      containers:
        - image: docker.io/openshift/hello-openshift
          env:
            - name: RESPONSE
              value: "Hello Serverless!"

  2. 运行以下命令应用 Knative 服务 YAML

    $ oc apply -f <filename>

  3. 检查 Knative 服务的状态

    命令示例
    $ oc get ksvc -n test-namespace -o yaml
    输出示例
    apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: test-webapp
  namespace: test-namespace
# spec:
# ...
status:
  address:
    # cluster-local-domain:
    url: https://helloworld.test.svc.cluster.local (1)
    1 如果您启用了cluster-local-domain-tls，您将看到 HTTPS URL。

  4. 要验证是否启用了system-internal-tls，请运行以下命令检查 Queue-Proxy 日志的输出

    命令示例
    $ oc logs your-pod -n test-namespace -c queue-proxy | grep -E 'certDir|Certificate|tls'

    如果您看到类似以下内容的行，则system-internal-tls已启用

    {"severity":"INFO","timestamp":"2024-01-03T07:07:32.892810888Z","logger":"queueproxy","caller":"certificate/watcher.go:62","message":"Starting to watch the following directories for changes{certDir 15 0 /var/lib/knative/certs <nil>} {keyDir 15 0 /var/lib/knative/certs <nil>}","commit":"86420f2-dirty","knative.dev/key":"first/helloworld-00001","knative.dev/pod":"helloworld-00001-deployment-75fbb7d488-qgmxx"}
{"severity":"INFO","timestamp":"2024-01-03T07:07:32.89397512Z","logger":"queueproxy","caller":"certificate/watcher.go:131","message":"Certificate and/or key have changed on disk and were reloaded.","commit":"86420f2-dirty","knative.dev/key":"first/helloworld-00001","knative.dev/pod":"helloworld-00001-deployment-75fbb7d488-qgmxx"}
{"severity":"INFO","timestamp":"2024-01-03T07:07:32.894232939Z","logger":"queueproxy","caller":"sharedmain/main.go:282","message":"Starting tls server admin:8022","commit":"86420f2-dirty","knative.dev/key":"first/helloworld-00001","knative.dev/pod":"helloworld-00001-deployment-75fbb7d488-qgmxx"}
{"severity":"INFO","timestamp":"2024-01-03T07:07:32.894268548Z","logger":"queueproxy","caller":"sharedmain/main.go:282","message":"Starting tls server main:8112","commit":"86420f2-dirty","knative.dev/key":"first/helloworld-00001","knative.dev/pod":"helloworld-00001-deployment-75fbb7d488-qgmxx"}