搜索

3.7. 配置网络

download PDF

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.42. 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。
  • OPTIONAL:如果您 使用网络策略配置多租户隔离 时,还必须将 allow-from-openshift-apiserverallow-from-workspaces-namespaces NetworkPolicies 应用到 openshift-devspacesallow-from-openshift-apiserver NetworkPolicy 允许将 openshift-apiserver 命名空间的传入流量到 devworkspace-webhook-server 启用 Webhook。allow-from-workspaces-namespaces NetworkPolicy 允许每个用户项目的传入流量到 che-gateway pod。

    例 3.43. allow-from-openshift-apiserver.yaml

    apiVersion: networking.k8s.io/v1
    kind: NetworkPolicy
    metadata:
      name: allow-from-openshift-apiserver
      namespace: openshift-devspaces   1
    spec:
      podSelector:
        matchLabels:
          app.kubernetes.io/name: devworkspace-webhook-server   2
      ingress:
        - from:
            - podSelector: {}
              namespaceSelector:
                matchLabels:
                  kubernetes.io/metadata.name: openshift-apiserver
      policyTypes:
        - Ingress
    1
    OpenShift Dev Spaces 命名空间。默认值为 openshift-devspaces
    2
    podSelector 仅选择 devworkspace-webhook-server pod

    例 3.44. allow-from-workspaces-namespaces.yaml

    apiVersion: networking.k8s.io/v1
    kind: NetworkPolicy
    metadata:
      name: allow-from-workspaces-namespaces
      namespace: openshift-devspaces   1
    spec:
      podSelector:
        matchLabels:
          app.kubernetes.io/component: che-gateway   2
      ingress:
        - from:
            - podSelector: {}
              namespaceSelector:
                matchLabels:
                  app.kubernetes.io/component: workspaces-namespace
      policyTypes:
        - Ingress
    1
    OpenShift Dev Spaces 命名空间。默认值为 openshift-devspaces
    2
    podSelector 只选择 che-gateway 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
    自定义 Red Hat OpenShift Dev Spaces 服务器主机名
    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-devspaces-*.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 服务器日志中验证导入的证书计数是否不是 null:

    $ 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& gt;,并等待工作区启动。
  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. 验证 universal-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 名称 < 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. 添加标签和注解

3.7.4.1. 配置 OpenShift 路由以使用路由器分片

您可以配置标签、注解和域,以用于 路由器分片

先决条件

流程

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

    spec:
      networking:
        labels: <labels> 1
        domain: <domain> 2
        annotations: <annotations> 3
    1
    目标入口控制器用来过滤到服务的 Routes 集合的无结构键值映射。
    2
    目标入口控制器服务的 DNS 名称。
    3
    与资源存储的无结构键值映射。
Red Hat logoGithubRedditYoutubeTwitter

学习

尝试、购买和销售

社区

关于红帽文档

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

让开源更具包容性

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

關於紅帽

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

© 2024 Red Hat, Inc.