3.7. 配置网络


3.7.1. 配置网络策略

默认情况下,OpenShift 集群中的所有 Pod 都可以相互通信,即使它们位于不同的命名空间中。在 OpenShift Dev Spaces 上下文中,这会导致一个用户项目中的工作空间 Pod 将流量发送到另一个用户项目中的另一个工作区 Pod。

为安全起见,可以使用 NetworkPolicy 对象配置多租户隔离来限制用户项目中的 Pod 的所有传入通信。但是,OpenShift Dev Spaces 项目中的 Pod 必须能够与用户项目中的 Pod 通信。

先决条件

  • OpenShift 集群具有网络限制,如多租户隔离。

流程

  • allow-from-openshift-devspaces NetworkPolicy 应用到每个用户项目。allow-from-openshift-devspaces NetworkPolicy 允许从 OpenShift Dev Spaces 命名空间进入到用户项目中的所有 Pod 的流量。

    例 3.34. allow-from-openshift-devspaces.yaml

    apiVersion: networking.k8s.io/v1
    kind: NetworkPolicy
    metadata:
        name: allow-from-openshift-devspaces
    spec:
        ingress:
        - from:
            - namespaceSelector:
                matchLabels:
                    kubernetes.io/metadata.name: openshift-devspaces   1
        podSelector: {}   2
        policyTypes:
        - Ingress
    1
    OpenShift Dev Spaces 命名空间。默认为 openshift-devspaces
    2
    podSelector 选择项目中的所有 Pod。

3.7.2. 配置 Dev Spaces 主机名

此流程描述了如何配置 OpenShift Dev Spaces 来使用自定义主机名。

先决条件

  • 具有对目标 OpenShift 集群的管理权限的活跃 oc 会话。请参阅 CLI 入门
  • 生成证书和私钥文件。
重要

要生成私钥和证书的对,必须将相同的证书颁发机构(CA)用作其他 OpenShift Dev Spaces 主机。

重要

要求 DNS 供应商将自定义主机名指向集群入口。

流程

  1. 为 OpenShift Dev Spaces 预先创建一个项目:

    $ oc create project openshift-devspaces
  2. 创建 TLS secret:

    $ oc create secret TLS <tls_secret_name> \ 1
    --key <key_file> \ 2
    --cert <cert_file> \ 3
    -n openshift-devspaces
    1
    TLS secret 名称
    2
    带有私钥的文件
    3
    包含证书的文件
  3. 在 secret 中添加所需的标签:

    $ oc label secret <tls_secret_name> \ 1
    app.kubernetes.io/part-of=che.eclipse.org -n openshift-devspaces
    1
    TLS secret 名称
  4. 配置 CheCluster 自定义资源。请参阅 第 3.1.2 节 “使用 CLI 配置 CheCluster 自定义资源”

    spec:
      networking:
        hostname: <hostname>     1
        tlsSecretName: <secret>  2
    1
    Custom Red Hat OpenShift Dev Spaces server hostname
    2
    TLS secret 名称
  5. 如果已经部署了 OpenShift Dev Spaces,请等待所有 OpenShift Dev Spaces 组件完成。

3.7.3. 将不受信任的 TLS 证书导入到 Dev Spaces

OpenShift Dev Spaces 组件与外部服务通信使用 TLS 加密。它们需要由可信证书颁发机构(CA)签名的 TLS 证书。因此,您必须导入到 OpenShift Dev Spaces 中由外部服务使用的所有不可信 CA 链,例如:

  • 代理
  • 身份提供程序(OIDC)
  • 源代码存储库供应商(Git)

OpenShift Dev Spaces 在 OpenShift Dev Spaces 项目中使用标记的配置映射作为 TLS 证书的源。配置映射可以有一个任意数量的密钥,每个密钥都有随机的证书。

注意

当 OpenShift 集群包含通过 cluster- wide-proxy 配置 添加的集群范围的可信 CA 证书时,OpenShift Dev Spaces Operator 会检测到它们,并使用 config.openshift.io/inject-trusted-cabundle="true" 标签自动注入配置映射。根据此注解,OpenShift 会自动在配置映射的 ca-bundle.crt 键内自动注入集群范围的可信 CA 证书。

先决条件

  • 具有对目标 OpenShift 集群的管理权限的活跃 oc 会话。请参阅 CLI 入门
  • openshift-devspaces 项目存在。
  • 对于要导入的每个 CA 链:使用 PEM 格式的 root CA 和中间证书,使用 ca-cert-for-devspaces- <count>.pem 文件。

流程

  1. 将要导入的所有 CA 链 PEM 文件串联到 custom-ca-certificates.pem 文件中,并删除与 Java 信任存储不兼容的返回字符。

    $ cat ca-cert-for-{prod-id-short}-*.pem | tr -d '\r' > custom-ca-certificates.pem
  2. 使用所需 TLS 证书创建 custom-ca-certificates 配置映射:

    $ oc create configmap custom-ca-certificates \
        --from-file=custom-ca-certificates.pem \
        --namespace=openshift-devspaces
  3. 标记 custom-ca-certificates 配置映射:

    $ oc label configmap custom-ca-certificates \
        app.kubernetes.io/component=ca-bundle \
        app.kubernetes.io/part-of=che.eclipse.org \
        --namespace=openshift-devspaces
  4. 如果 OpenShift Dev Spaces 之前尚未部署,则部署 OpenShift Dev Spaces。否则,请等待 OpenShift Dev Spaces 组件的推出完成。
  5. 重启正在运行的工作区以使更改生效。

验证步骤

  1. 验证配置映射是否包含自定义 CA 证书。这个命令以 PEM 格式返回您的自定义 CA 证书:

    $ oc get configmap \
        --namespace=openshift-devspaces \
        --output='jsonpath={.items[0:].data.custom-ca-certificates\.pem}' \
        --selector=app.kubernetes.io/component=ca-bundle,app.kubernetes.io/part-of=che.eclipse.org
  2. 验证 OpenShift Dev Spaces pod 包含挂载 ca-certs-merged 配置映射的卷:

    $ oc get pod \
        --selector=app.kubernetes.io/component=devspaces \
        --output='jsonpath={.items[0].spec.volumes[0:].configMap.name}' \
        --namespace=openshift-devspaces \
        | grep ca-certs-merged
  3. 验证 OpenShift Dev Spaces 服务器容器是否有自定义 CA 证书。这个命令以 PEM 格式返回您的自定义 CA 证书:

    $ oc exec -t deploy/devspaces \
        --namespace=openshift-devspaces \
        -- cat /public-certs/custom-ca-certificates.pem
  4. 在 OpenShift Dev Spaces 服务器中验证导入的证书计数是否不为空:

    $ oc logs deploy/devspaces --namespace=openshift-devspaces \
        | grep custom-ca-certificates.pem
  5. 列出证书的 SHA256 指纹:

    $ for certificate in ca-cert*.pem ;
      do openssl x509 -in $certificate -digest -sha256 -fingerprint -noout | cut -d= -f2;
      done
  6. 验证 OpenShift Dev Spaces 服务器 Java 信任存储是否包含具有相同指纹的证书:

    $ oc exec -t deploy/devspaces --namespace=openshift-devspaces -- \
        keytool -list -keystore /home/user/cacerts \
        | grep --after-context=1 custom-ca-certificates.pem
  7. 启动工作区,获取其创建的项目名称:< workspace_namespace > 并等待工作区启动。
  8. 验证 che-trusted-ca-certs 配置映射是否包含您的自定义 CA 证书。这个命令以 PEM 格式返回您的自定义 CA 证书:

    $ oc get configmap che-trusted-ca-certs \
        --namespace=<workspace_namespace> \
        --output='jsonpath={.data.custom-ca-certificates\.custom-ca-certificates\.pem}'
  9. 验证工作区 pod 是否挂载 che-trusted-ca-certs 配置映射:

    $ oc get pod \
        --namespace=<workspace_namespace> \
        --selector='controller.devfile.io/devworkspace_name=<workspace_name>' \
        --output='jsonpath={.items[0:].spec.volumes[0:].configMap.name}' \
        | grep che-trusted-ca-certs
  10. 验证 generic -developer-image 容器(或工作区 devfile 中定义的容器)挂载 che-trusted-ca-certs 卷:

    $ oc get pod \
        --namespace=<workspace_namespace> \
        --selector='controller.devfile.io/devworkspace_name=<workspace_name>' \
        --output='jsonpath={.items[0:].spec.containers[0:]}' \
        | jq 'select (.volumeMounts[].name == "che-trusted-ca-certs") | .name'
  11. 获取工作区 pod 名称 &lt ;workspace_pod_name>

    $ oc get pod \
        --namespace=<workspace_namespace> \
        --selector='controller.devfile.io/devworkspace_name=<workspace_name>' \
        --output='jsonpath={.items[0:].metadata.name}' \
  12. 验证工作区容器是否具有自定义 CA 证书。这个命令以 PEM 格式返回您的自定义 CA 证书:

    $ oc exec <workspace_pod_name> \
        --namespace=<workspace_namespace> \
        -- cat /public-certs/custom-ca-certificates.custom-ca-certificates.pem

3.7.4. 配置 OpenShift 路由

如果您的组织需要,您可以配置 OpenShift Route 标签和注解。

先决条件

  • 具有对目标 OpenShift 集群的管理权限的活跃 oc 会话。请参阅 CLI 入门
  • 在 OpenShift 中运行的一个 OpenShift Dev Spaces 实例。

流程

  • 配置 CheCluster 自定义资源。请参阅 第 3.1.2 节 “使用 CLI 配置 CheCluster 自定义资源”

    spec:
      components:
        cheServer:
          extraProperties:
            CHE_INFRA_KUBERNETES_INGRESS_LABELS: <labels> 1
            CHE_INFRA_KUBERNETES_INGRESS_ANNOTATIONS__JSON: "<annotations>" 2
        networking:
          labels: <labels> 3
          annotations: <annotations> 4
    1 3
    OpenShift Route: key1=value1,key2=value2 的以逗号分隔的标签列表。
    2 4
    JSON 格式的 OpenShift Route 注解: {"key1": "value1", "key2" : "value2"}.

3.7.5. 配置 OpenShift 路由

您可以配置标签、注解和域,供 OpenShift Route 使用 路由器分片

先决条件

流程

  • 配置 CheCluster 自定义资源。请参阅 第 3.1.2 节 “使用 CLI 配置 CheCluster 自定义资源”

    spec:
      components:
        cheServer:
          extraProperties:
            CHE_INFRA_OPENSHIFT_ROUTE_LABELS: <labels> 1
            CHE_INFRA_OPENSHIFT_ROUTE_HOST_DOMAIN__SUFFIX: <domain> 2
        networking:
          labels: <labels> 3
          domain: <domain> 4
          annotations: <annotations> 5
    1 3
    目标入口控制器用来将路由集合过滤为服务的一组标签列表。
    2 4
    目标入口控制器服务的 DNS 名称。
    5
    存储在资源的非结构化键值映射。
Red Hat logoGithubRedditYoutubeTwitter

学习

尝试、购买和销售

社区

关于红帽文档

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

让开源更具包容性

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

關於紅帽

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

© 2024 Red Hat, Inc.