3.7.3. 将不信任的 TLS 证书导入到 OpenShift Dev Spaces
默认情况下，OpenShift Dev Spaces 组件之间的外部通信通过 TLS 加密。OpenShift Dev Spaces 组件与代理、源代码存储库和身份提供程序等外部服务的通信可能还需要 TLS。所有使用 TLS 加密的通信都需要使用由可信证书颁发机构(CA)签名的 TLS 证书。
当 OpenShift Dev Spaces 组件或外部服务使用的证书由不信任的 CA 签名时，您必须将 CA 证书导入到 OpenShift Dev Spaces 实例，以便每个 OpenShift Dev Spaces 组件将证书视为可信 CA 签名。您必须在以下情况下完成此操作：
- 底层 OpenShift 集群使用由不受信任的 CA 签名的 TLS 证书。OpenShift Dev Spaces 服务器或工作空间组件连接到外部 OIDC 供应商或使用由不受信任的 CA 签名的 TLS 证书的 Git 服务器。
OpenShift Dev Spaces 使用项目中标记的 ConfigMap 对象作为 TLS 证书的源。ConfigMap 对象可以有任意数量的密钥，各自具有随机数量的证书。
当 OpenShift 集群包含通过 集群范围的代理配置添加的集群范围 可信 CA 证书时，OpenShift Dev Spaces Operator 会检测到它们并自动注入 ConfigMap 对象。OpenShift Dev Spaces 会自动使用 config.openshift.io/inject-trusted-cabundle="true" 标签标记 ConfigMap。基于此注解，OpenShift 会在 ConfigMap 对象的 ca-bundle.crt 键内自动注入集群范围的可信 CA 证书。
一些 OpenShift Dev Spaces 组件需要一个完整的证书链来信任端点。如果使用中间证书配置集群，请将整个链（包括自签名 root）添加到 OpenShift Dev Spaces。
3.7.3.1. 在 OpenShift Dev Spaces 中添加新 CA 证书
证书文件通常存储为 Base64 文件，扩展带有 .pem、.crt、.ca-bundle 等等。包含证书文件的所有 secret 应该使用 Base64 编码的证书，而不是二进制编码的证书。以下流程适用于已安装和运行的实例，以及要安装的实例。
先决条件
-
具有目标 OpenShift 集群的管理权限的活跃
oc会话。请参阅 CLI 入门。 - 存在 OpenShift Dev Spaces 的命名空间。
OpenShift Dev Spaces 已经使用一些保留的文件名自动将证书注入
ConfigMap对象中。避免使用以下保留文件名保存您的证书：-
ca-bundle.crt -
ca.crt
-
流程
保存导入本地文件系统所需的证书。
小心具有简介短语
BEGIN TRUSTED CERTIFICATECERTIFICATE 的证书可能包括在 PEMTRUSTED CERTIFICATE格式，它不会被 Java 不支持。使用以下命令将其转换为支持的CERTIFICATE格式：-
openssl x509 -in cert.pem -out cert.cer
-
使用所需的 TLS 证书创建新
ConfigMap对象：$ oc create configmap custom-certs --from-file=<bundle-file-path> -n=openshift-devspaces要应用多个捆绑包，请添加另一个
-from-file= <bundle_file_path>。另外，还可创建另一个ConfigMap对象。使用
app.kubernetes.io/part-of=che.eclipse.org和app.kubernetes.io/component=ca-bundle标签标记创建的ConfigMap对象：$ oc label configmap custom-certs app.kubernetes.io/part-of=che.eclipse.org app.kubernetes.io/component=ca-bundle -n openshift-devspaces
- 如果 OpenShift Dev Spaces 之前没有部署，则部署 OpenShift Dev Spaces。否则等待 OpenShift Dev Spaces 推出完成。
- 重启正在运行的工作区以使更改生效。
