証明書の概要

このページでは、Automation Suite のインストールに必要なすべての証明書と、証明書ローテーション プロセスの原則について説明します。

重要: 自己署名証明書を置き換える際に指定する必要がある証明書の詳細については、「証明書の要件」をご覧ください。

信頼証明書の仕組みを理解する

Automation Suite 内での製品間のサービス間通信は、クラスターの FQDN を介して行われます。製品が内部 URL を使用して相互に通信することはできません。たとえば、Orchestrator は https://automationsuite.mycompany.com/identity を介して Identity Server に接続し、ユーザー認証を行うことができます。

2 つの異なる Automation Suite 製品はクラスターの FQDN を使用する必要がありますが、複数のマイクロサービスを含めることもできます。これらのマイクロサービスは内部 URL を使用して相互に通信できます。

通信の仕組みを理解する

次の図とフローでは、クライアントがどのようにサービスに接続し、認証が ID サービスを介してどのように行われるかを説明します。

1. クライアントは、URL を使用するサービス (Orchestrator、Apps、Insights など) に次の URL を使用して接続します: https://automationsuite.mycompany.com/myorg/mytenant/service_。
2. Istio は、その呼び出しをインターセプトし、service_ のパスに基づいて呼び出しを特定のサービスに転送します。
3. そのサービスは、ID サービスを呼び出して、ロボットからの受信リクエストを https://automationsuite.mycompany.com/myorg/mytenant/identity_ を介して認証します。
4. Istio は、その呼び出しをインターセプトし、identity_ のパスに基づいてリクエストを ID サービスに転送します。
5. ID サービスは、応答を結果とともに 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 サービスは、Identity Server を呼び出して、ロボットからの受信リクエストを https://automationsuite.mycompany.com/myorg/mytenant/identity_ を介して認証します。
4. Istio は、その呼び出しをインターセプトし、identity_ のパスに基づいてリクエストを Identity Server に転送します。
5. Identity Server は、応答を結果とともに Istio に返します。
6. Istio は、Orchestrator に応答を返します。呼び出しは HTTPS プロトコルを使用して行われるので、Istio は応答を TLS 証明書とともに返し、接続をセキュリティで保護します。Orchestrator は、Istio によって返されたサーバー証明書を信頼する場合、応答を承認します。信頼しない場合は、応答を拒否します。
7. Orchestrator は応答を準備し、Istio に返します。

8. Istio は、リクエストをロボットに転送して戻します。ロボット マシンが証明書を信頼する場合、リクエスト全体が成功します。信頼しない場合、リクエストは失敗します。

   
   

   

   
   

証明書に関連するコンテナー アーキテクチャを理解する

コンテナー レベル

この例では、コンテナーに専用のオペレーティング システム (RHEL OS) があり、サービスは RHEL OS 上で実行される Orchestrator に相当します。

すべての OS には、独自の証明書ストアがあります。 RHEL OS の場合、証明書信頼ストアは /etc/pki/ca-trust/ca/にあります。

RHEL OS では、すべての証明書がこのパスに保存されます。すべてのコンテナーに専用の証明書信頼ストアがあります。Automation Suite の構成の一環として、ルート証明書、すべての中間証明書、リーフ証明書を含むチェーン証明書全体が挿入され、このパスに保存されます。サービスはルート証明書と中間証明書を信頼するので、ルート証明書と中間証明書によって作成される他の証明書も自動的に信頼します。

ポッド レベル

Automation Suite 内では何百ものコンテナーが実行されています。すべてのサービスについて、これらの各コンテナーの証明書を手動で追加するのは手間のかかる作業です。しかし、Automation Suite には、この作業を支援する共有ボリュームと Init コンテナー cert-trustor が含まれています。Init は、ポッド内でアプリ コンテナーより先に実行される特殊なコンテナーであり、そのジョブが完了するとすぐにそのライフサイクルが終了します。

次の例では、Orchestrator サービスは 1 つのポッドで実行されています。なお、1 つのポッドに複数のコンテナーを含めることができます。このポッドに、Cert-trustor という Init コンテナーを 1 つ以上挿入します。このコンテナーに、ルート証明書、中間証明書、リーフ証明書が含まれます。

共有ボリュームは、Cert-trustor コンテナーと Orchestrator サービス コンテナーの両方にアタッチされます。 パスは RHEL OS 証明書信頼ストアと同じです ( /etc/pki/ca-trust/ca/source/anchors)。

Orchestrator を実行する前に、Cert-trustor は、/etc/pki/ca-trust/ca/source/anchors の場所にある共有ボリュームに証明書を追加するジョブを実行し、終了します。

証明書は、共有ボリュームを通じて Orchestrator サービスで利用できます。

Automation Suite のすべての証明書のリスト

インストール時に生成される証明書

Automation Suite のインストールの一環として、次の証明書が生成されます。

• 自己署名証明書。インストール時に生成され、3 か月間有効です。インストール後に、自己署名証明書をドメイン証明書に置き換える必要があります。「証明書を管理する」をご覧ください。

• Identity Server の証明書。認証で使用される JWT トークンに署名するために使われます。JWT トークンに署名するための証明書が提供されていない場合、Automation Suite は、現在設定されている TLS 証明書 (自己署名証明書またはユーザー提供の証明書) を使用します。有効期限は 90 日です。ID トークンに署名するための独自の証明書が欲しい場合は、「証明書を管理する」をご覧ください。
• RKE2 証明書が生成されます。既定では有効期限は 12 か月です。証明書の有効期限が既に切れている場合、または 90 日以内に有効期限が切れる場合は、RKE2 の再起動時にローテーションされます。

追加の証明書

• 有効化すると、SAML2 認証プロトコルでサービス証明書を使用できます。
• ユーザー名とパスワードを使用して Active Directory を構成する場合、LDAPS (SSL 経由の LDAP) は任意です。LDAPS を選択する場合は、証明書を提供する必要があります。この証明書は、Automation Suite の信頼されたルート証明機関に追加されます。詳細については、Microsoft のドキュメントをご覧ください。

この証明書は、Automation Suite の信頼されたルート証明機関に追加されます。

証明書の更新/ローテーションの仕組みを理解する

オンライン インストール

証明書は次の 2 つの場所に保存されます。

• istio-system の istio-ingressgateway-certs
• uipath 名前空間

istio-system および uipath 名前空間内の証明書を更新するには、sudo ./configureUiPathAS.sh tls-cert update コマンドを実行する必要があります。

ポッドは、その名前空間にあるシークレットにのみアクセスできます。たとえば、uipath 名前空間で実行されているポッドは、istio-system 名前空間に格納されているシークレットにはアクセスできません。そのため、証明書は両方の名前空間にコピーされます。

uipath 名前空間については、証明書を必要とするポッドに証明書をマウントし、新しい証明書を使用できるようにポッドを再起動します。

注:

シングルノードの評価のインストールでは、更新によってポッドがスケール ダウンされます。すべてのポッドがシャットダウンされ、再起動されます。この処理によってダウンタイムが発生します。

マルチノードの高可用性対応の運用環境のインストールの場合、更新はローリング デプロイ手法を使用して行われます。高可用性を実現するためにマイクロサービスに 2 つのポッドがある場合、更新によりポッドの 1 つが削除され、新しいバージョンのポッドが起動されます。新しいポッドが正常に起動すると、古いポッドは削除されます。古いポッドがまだ終了していない間は、短時間のダウンタイムが発生します。

オフライン インストール

オフライン デプロイでは、オンライン インストールに固有の証明書に加え、rootCA.crt と tls.crt が使用される場所が他に 2 つあります。証明書は ArgoCD と Docker レジストリで使用され、Docker と ArgoCD の両方の名前空間に保存されます。

次のコマンドを使用して、シークレットを確認できます。

# For docker registry
kubectl -n docker-registry get secrets docker-registry-tls -o yaml
# For Argocd
argocd cert list --cert-type https