4.8. 配置网络
4.8.1. 配置网络策略 复制链接链接已复制到粘贴板!
默认情况下,OpenShift 集群中的所有 Pod 都可以相互通信,即使它们位于不同的命名空间中。在 OpenShift Dev Spaces 中,这可能会导致一个用户项目中的工作区 Pod 将流量发送到其他用户项目中的另一个工作区 Pod。
为安全起见,可以使用 NetworkPolicy 对象配置多租户隔离,以限制用户项目中的所有传入的通信。但是,OpenShift Dev Spaces 项目中的 Pod 必须能够与用户项目中的 Pod 通信。
先决条件
- OpenShift 集群有网络限制,如多租户隔离。
流程
将
allow-from-openshift-devspacesNetworkPolicy 应用到每个用户项目。allow-from-openshift-devspacesNetworkPolicy 允许从 OpenShift Dev Spaces 命名空间的传入流量到用户项目中的所有 Pod。例 4.43.
allow-from-openshift-devspaces.yamlapiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: allow-from-openshift-devspaces spec: ingress: - from: - namespaceSelector: matchLabels: kubernetes.io/metadata.name: openshift-devspaces1 podSelector: {}2 policyTypes: - IngressOPTIONAL : 在使用网络策略应用配置多租户隔离时,还必须应用
allow-from-openshift-apiserver和allow-from-workspaces-namespacesNetworkPolicies 到openshift-devspaces。allow-from-openshift-apiserverNetworkPolicy 允许从openshift-apiserver命名空间中的传入流量到devworkspace-webhook-server启用 Webhook。allow-from-workspaces-namespacesNetworkPolicy 允许从每个用户项目的传入流量到che-gatewaypod。例 4.44.
allow-from-openshift-apiserver.yamlapiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: allow-from-openshift-apiserver namespace: openshift-devspaces1 spec: podSelector: matchLabels: app.kubernetes.io/name: devworkspace-webhook-server2 ingress: - from: - podSelector: {} namespaceSelector: matchLabels: kubernetes.io/metadata.name: openshift-apiserver policyTypes: - Ingress例 4.45.
allow-from-workspaces-namespaces.yamlapiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: allow-from-workspaces-namespaces namespace: openshift-devspaces1 spec: podSelector: {}2 ingress: - from: - podSelector: {} namespaceSelector: matchLabels: app.kubernetes.io/component: workspaces-namespace policyTypes: - Ingress- 第 4.2 节 “配置项目”
- 网络隔离
- 使用网络策略配置多租户隔离
4.8.2. 配置 Dev Spaces 主机名 复制链接链接已复制到粘贴板!
此流程描述了如何将 OpenShift Dev Spaces 配置为使用自定义主机名。
先决条件
-
对目标 OpenShift 集群具有管理权限的活动
oc会话。请参阅 CLI 入门。 - 生成证书和私钥文件。
要生成私钥和证书的对,相同的证书颁发机构(CA)必须与其他 OpenShift Dev Spaces 主机一起使用。
请求 DNS 供应商将自定义主机名指向集群入口。
流程
为 OpenShift Dev Spaces 预创建项目:
$ oc create project openshift-devspaces创建 TLS secret:
$ oc create secret TLS <tls_secret_name> \1 --key <key_file> \2 --cert <cert_file> \3 -n openshift-devspaces在 secret 中添加所需的标签:
$ oc label secret <tls_secret_name> \1 app.kubernetes.io/part-of=che.eclipse.org -n openshift-devspaces- 1
- TLS secret 名称
配置
CheCluster自定义资源。请参阅 第 4.1.2 节 “使用 CLI 配置 CheCluster 自定义资源”。spec: networking: hostname: <hostname>1 tlsSecretName: <secret>2 - 如果 OpenShift Dev Spaces 已部署,请等待所有 OpenShift Dev Spaces 组件的推出完成。
4.8.3. 将不可信 TLS 证书导入到 Dev Spaces 复制链接链接已复制到粘贴板!
OpenShift Dev Spaces 组件与外部服务通信通过 TLS 加密。它们需要由可信证书颁发机构(CA)签名的 TLS 证书。因此,您必须导入到 OpenShift Dev Spaces 中由外部服务使用的所有不受信任的 CA 链,例如:
- 代理
- 身份供应商(OIDC)
- 源代码存储库供应商(Git)
OpenShift Dev Spaces 使用 OpenShift Dev Spaces 项目中的标记 ConfigMap 作为 TLS 证书的源。ConfigMap 可以有任意数量的键,每个键都有随机数量的证书。Operator 将所有 ConfigMap 合并到一个标题为 ca-certs-merged 中,并将它作为卷挂载到 OpenShift Dev Spaces 服务器、仪表板和工作区 Pod 中。默认情况下,Operator 会在两个位置的用户工作区中挂载 ca-certs-merged ConfigMap: /public-certs 和 /etc/pki/ca-trust/extracted/pem。/etc/pki/ca-trust/extracted/pem 目录是系统在红帽(如 CentOS、Fedora)上为可信证书颁发机构提取的 CA 证书的位置。当用户的工作空间启动并运行时,CLI 工具会自动使用来自系统可信位置的证书。
当 OpenShift 集群包含通过 cluster- wide-proxy 配置 添加的集群范围可信 CA 证书时,OpenShift Dev Spaces Operator 会检测到它们,并使用 config.openshift.io/inject-trusted-cabundle="true" 标签自动注入 ConfigMap。根据此注解,OpenShift 会在 ConfigMap 的 ca-bundle.crt 键中自动注入集群范围的可信 CA 证书。
先决条件
流程
将所有 CA 链 PEM 文件链到
custom-ca-certificates.pem文件中,并删除与 Java 信任存储不兼容的返回字符。$ cat ca-cert-for-devspaces-*.pem | tr -d '\r' > custom-ca-certificates.pem使用所需的 TLS 证书创建
custom-ca-certificatesConfigMap:$ oc create configmap custom-ca-certificates \ --from-file=custom-ca-certificates.pem \ --namespace=openshift-devspaces标记
custom-ca-certificatesConfigMap:$ oc label configmap custom-ca-certificates \ app.kubernetes.io/component=ca-bundle \ app.kubernetes.io/part-of=che.eclipse.org \ --namespace=openshift-devspaces- 如果之前尚未部署,部署 OpenShift Dev Spaces。否则,请等待 OpenShift Dev Spaces 组件的推出完成。
- 重启正在运行的工作区以使更改生效。
验证步骤
验证 ConfigMap 是否包含您的自定义 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在 OpenShift Dev Spaces 服务器日志中验证导入的证书计数是否不是 null :
$ oc logs deploy/devspaces --namespace=openshift-devspaces \ | grep tls-ca-bundle.pem- 启动一个工作区,获取创建它的项目名称:< workspace_namespace > 并等待工作区启动。
验证
ca-certs-mergedConfigMap 是否包含您的自定义 CA 证书。此命令以 PEM 格式返回 OpenShift Dev Spaces CA 捆绑包证书:$ oc get configmap che-trusted-ca-certs \ --namespace=<workspace_namespace> \ --output='jsonpath={.data.tls-ca-bundle\.pem}'验证工作区 pod 是否挂载
ca-certs-mergedConfigMap:$ oc get pod \ --namespace=<workspace_namespace> \ --selector='controller.devfile.io/devworkspace_name=<workspace_name>' \ --output='jsonpath={.items[0:].spec.volumes[0:].configMap.name}' \ | grep ca-certs-merged获取工作区 pod 名称 < workspace_pod_name>:
$ oc get pod \ --namespace=<workspace_namespace> \ --selector='controller.devfile.io/devworkspace_name=<workspace_name>' \ --output='jsonpath={.items[0:].metadata.name}' \验证工作区容器是否具有您的自定义 CA 证书。此命令以 PEM 格式返回 OpenShift Dev Spaces CA 捆绑包证书:
$ oc exec <workspace_pod_name> \ --namespace=<workspace_namespace> \ -- cat /public-certs/tls-ca-bundle.pem
其他资源
4.8.4. 添加标签和注解 复制链接链接已复制到粘贴板!
4.8.4.1. 配置 OpenShift 路由以使用路由器划分 复制链接链接已复制到粘贴板!
您可以为 OpenShift Route 配置标签、注解和域,以用于 路由器分片。
先决条件
-
具有 OpenShift 集群管理权限的活跃的
oc会话。请参阅 OpenShift CLI 入门。 -
DSC.请参阅:第 2.2 节 “安装 dsc 管理工具”。
流程
配置
CheCluster自定义资源。请参阅 第 4.1.2 节 “使用 CLI 配置 CheCluster 自定义资源”。spec: networking: labels: <labels>1 domain: <domain>2 annotations: <annotations>3