证书概述

EKS/AKS 上的 Automation Suite 安装所需的证书，包括信任架构和证书轮换流程。

本页介绍 Automation Suite 安装所需的所有证书，以及证书轮换流程的原则。

重要提示：

有关替换自签名证书时必须提供的证书的详细信息，请参阅证书要求。

了解信任证书的工作方式

Automation Suite 内产品之间的服务间通信通过集群的 FQDN 完成。 产品无法使用内部 URL 相互通信。 例如，Orchestrator 可以通过https://automationsuite.mycompany.com/identity连接到身份服务器以进行用户身份验证。

虽然两个不同的 Automation Suite 产品必须使用集群的 FQDN，但它们也可以包含多个微服务。 这些微服务可以使用内部 URL 相互通信。

了解通信的工作方式

下图和流程说明了客户端如何连接到服务，以及如何通过身份服务完成身份验证。

1. 客户端使用以下 URL 与服务（即 Orchestrator、Apps、Insights 等）建立连接： https://automationsuite.mycompany.com/myorg/mytenant/service_ 。

2. Istio 拦截调用，并根据service_的路径，将调用转发到特定服务。

3. 该服务调用身份服务，以通过https://automationsuite.mycompany.com/myorg/mytenant/identity_对来自客户端的传入请求进行身份验证。

4. Istio 拦截调用，并根据路径identity_将请求转发到身份服务。

5. 身份服务将响应及其结果返回给 Istio。

6. Istio 将响应返回给服务。 由于调用是使用 HTTPS 协议进行的，因此 Istio 返回带有 TLS 证书的响应，以确保连接安全。 如果服务信任 Istio 返回的服务器证书，则会批准响应。 否则，服务将拒绝响应。

7. 该服务准备响应并将其发送回 Istio。

8. Istio 将请求转发回客户端。 如果客户端计算机信任证书，则整个请求都会成功。 否则，请求将失败。

   

了解机器人与 Orchestrator 的通信方式

本节介绍机器人尝试连接到 Automation Suite 中的 Orchestrator 的场景。 下图和流程说明了机器人如何连接到 Orchestrator，以及如何通过 Identity Server 完成身份验证。

1. 机器人使用以下 URL 与 Orchestrator 建立连接： https://automationsuite.mycompany.com/myorg/mytenant/orchestrator_

2. Istio 拦截调用，并根据orchestrator_路径将其转发到 Orchestrator 服务。

3. Orchestrator 服务调用身份服务器，以通过https://automationsuite.mycompany.com/myorg/mytenant/identity_对来自机器人的传入请求进行身份验证。

4. Istio 拦截调用，并根据identity_路径将请求转发到 Identity Server。

5. Identity Server 将响应和结果返回给 Istio。

6. Istio 将响应返回给 Orchestrator。 由于调用是使用 HTTPS 协议进行的，因此 Istio 返回带有 TLS 证书的响应，因此该连接是安全的。 如果 Orchestrator 信任 Istio 返回的服务器证书，则它也会批准响应。 否则，Orchestrator 将拒绝响应。

7. Orchestrator 准备响应并将其发送回 Istio。

8. Istio 将请求转发回机器人。 如果机器人计算机信任证书，则整个请求都会成功。 否则，请求将失败。

   

了解与证书相关的容器架构

容器级别

下图显示了一个拥有自己的操作系统和证书信任存储区的容器。

在此示例中，容器具有自己的操作系统 (RHEL 操作系统)，服务可以表示在 RHEL 操作系统之上运行的 Orchestrator。

每个操作系统都有自己的证书存储区。 对于 RHEL 操作系统，“证书信任存储区”位于/etc/pki/ca-trust/ca/ 。

此路径是 RHEL 操作系统存储所有证书的位置。每个容器都有自己的证书信任存储区。

作为 Automation Suite 配置的一部分，我们会注入包含根证书、所有中间证书以及叶证书的整个链证书，并将其存储在此路径中。由于服务信任根证书和中间证书，因此它们会自动信任由根证书和中间证书创建的任何其他证书。

Pod 级别

Automation Suite 中有数百个容器正在运行。 为所有服务的每个容器手动添加证书将是一项艰巨的任务。 但是，Automation Suite 包含一个共享卷和一个初始化容器证书信任程序，以帮助完成此任务。 Init 是一个专用容器，在 Pod 中在应用程序容器之前运行，其生命周期在完成作业后立即结束。

在以下示例中，Orchestrator 服务在一个 Pod 中运行。提醒一下，一个 Pod 可以包含多个容器。

1. Pod 包含一个名为Cert-trustor 的Init 容器，其中包含根证书、中间证书和分支证书。

2. 共享卷使用与 RHEL 操作系统证书信任存储相同的路径附加到证书信任程序容器和 Orchestrator 服务容器： /etc/pki/ca-trust/ca/source/anchors 。

3. 在 Orchestrator 运行之前，证书信任程序会将证书添加到该位置的共享卷中，然后终止。

4. 证书通过共享卷对 Orchestrator 服务可用。

   

Automation Suite 中所有证书的清单

安装期间生成的证书

作为 Automation Suite 安装的一部分，系统将生成以下证书：

• 安装时生成的自签名证书。建议您在安装后将自签名证书替换为域证书。请参阅管理证书。
• 用于对身份验证中使用的 JWT 令牌进行签名的Identity Server 证书。如果未提供用于对 JWT 令牌进行签名的证书，Automation Suite 将使用当前配置的 TLS 证书（自签名证书或客户提供的）。如果您想使用自己的证书对身份令牌进行签名，请参阅管理证书。

其他证书

• 如果启用，SAML2 身份验证协议可以使用服务证书。
• 如果使用用户名和密码配置 Active Directory，则 LDAPS (LDAP Over SSL) 为可选项。如果选择 LDAPS，则必须提供证书。系统会将此证书添加到 Automation Suite 的受信任根证书颁发机构中。有关详细信息，请参阅Microsoft 文档。

了解证书更新/轮换的工作原理

证书存储在两个位置：

• { istio-system中的istio-ingressgateway-certs }
• uipath命名空间

要更新istio-system和uipath命名空间中的证书，您必须运行uipathctl config update-tls-certificates命令。

Pod 只能访问其命名空间中的密码。 例如，在 uipath 命名空间中运行的 Pod 无法访问存储在 istio-system 命名空间中的密码。 因此，证书将复制到两个命名空间中。

对于uipath命名空间，我们将证书装载到需要证书的 Pod 中，并重新启动 Pod，以便它们可以使用新证书。

备注：

更新使用滚动部署方法进行。如果微服务具有两个用于高可用性的 Pod，则更新将删除其中一个 Pod，并显示新版本的 Pod。新机器人成功启动后，旧机器人将被删除。在旧 Pod 尚未终止之前，将有一个短暂的停机时间。