- 概要
- 要件
- インストール
- インストール後
- クラスターの管理
- 監視とアラート機能
- 移行とアップグレード
- 製品固有の設定
- ベストプラクティスとメンテナンス
- トラブルシューティング
- 移行後にログインできない
- 管理ポータルのタイムアウト期間を設定する
- 基になるディレクトリ接続を更新する
- Kinit: Cannot Find KDC for Realm <AD Domain> While Getting Initial Credentials
- kinit: Keytab contains no suitable keys for *** while getting initial credentials
- GSSAPI operation failed with error: An invalid status code was supplied (Client's credentials have been revoked).
- Login Failed for User <ADDOMAIN><aduser>.Reason: The Account Is Disabled.
- Alarm received for failed kerberos-tgt-update job
- SSPI Provider: Server not found in Kerberos database
- Automation Suite 診断ツールを使用する
- Automation Suite サポート バンドル ツールを使用する
- ログを確認する
証明書の概要
https://automationsuite.mycompany.com/identity
を介して Identity Server に接続し、ユーザー認証を行うことができます。
2 つの異なる Automation Suite 製品はクラスターの FQDN を使用する必要がありますが、複数のマイクロサービスを含めることもできます。これらのマイクロサービスは内部 URL を使用して相互に通信できます。
次の図とフローでは、クライアントがどのようにサービスに接続し、認証が ID サービスを介してどのように行われるかを説明します。
- クライアントは、URL を使用するサービス (Orchestrator、Apps、Insights など) に次の URL を使用して接続します:
https://automationsuite.mycompany.com/myorg/mytenant/service_
。 - Istio は、その呼び出しをインターセプトし、
service_
のパスに基づいて呼び出しを特定のサービスに転送します。 - そのサービスは、ID サービスを呼び出して、ロボットからの受信リクエストを
https://automationsuite.mycompany.com/myorg/mytenant/identity_
を介して認証します。 - Istio は、その呼び出しをインターセプトし、
identity_
のパスに基づいてリクエストを ID サービスに転送します。 - ID サービスは、応答を結果とともに Istio に返します。
- Istio は、サービスに応答を返します。呼び出しは HTTPS プロトコルを使用して行われるので、Istio は応答を TLS 証明書とともに返し、接続をセキュリティで保護します。サービスは、Istio によって返されたサーバー証明書を信頼する場合、応答を承認します。信頼しない場合は、応答を拒否します。
- サービスは応答を準備し、Istio に返します。
-
Istio は、リクエストをクライアントに転送して戻します。クライアント マシンが証明書を信頼する場合、リクエスト全体が成功します。信頼しない場合、リクエストは失敗します。
このセクションでは、ロボットが Automation Suite 内の Orchestrator に接続を試みる場合のシナリオについて説明します。次の図とフローでは、ロボットがどのように Orchestrator に接続し、認証が Identity Server を介してどのように行われるかを説明します。
- ロボットは、次の URL を使用して Orchestrator と接続します:
https://automationsuite.mycompany.com/myorg/mytenant/orchestrator_
。 - Istio は、その呼び出しをインターセプトし、
orchestrator_
のパスに基づいて Orchestrator サービスに転送します。 - Orchestrator サービスは、Identity Server を呼び出して、ロボットからの受信リクエストを
https://automationsuite.mycompany.com/myorg/mytenant/identity_
を介して認証します。 - Istio は、その呼び出しをインターセプトし、
identity_
のパスに基づいてリクエストを Identity Server に転送します。 - Identity Server は、応答を結果とともに Istio に返します。
- Istio は、Orchestrator に応答を返します。呼び出しは HTTPS プロトコルを使用して行われるので、Istio は応答を TLS 証明書とともに返し、接続をセキュリティで保護します。Orchestrator は、Istio によって返されたサーバー証明書を信頼する場合、応答を承認します。信頼しない場合は、応答を拒否します。
- Orchestrator は応答を準備し、Istio に返します。
-
Istio は、リクエストをロボットに転送して戻します。ロボット マシンが証明書を信頼する場合、リクエスト全体が成功します。信頼しない場合、リクエストは失敗します。
この例では、コンテナーに専用のオペレーティング システム (RHEL OS) があり、サービスは RHEL OS 上で実行される Orchestrator に相当します。
/etc/pki/ca-trust/ca/
にあります。
RHEL OS では、すべての証明書がこのパスに保存されます。すべてのコンテナーに専用の証明書信頼ストアがあります。Automation Suite の構成の一環として、ルート証明書、すべての中間証明書、リーフ証明書を含むチェーン証明書全体が挿入され、このパスに保存されます。サービスはルート証明書と中間証明書を信頼するので、ルート証明書と中間証明書によって作成される他の証明書も自動的に信頼します。
Automation Suite 内では何百ものコンテナーが実行されています。すべてのサービスについて、これらの各コンテナーの証明書を手動で追加するのは手間のかかる作業です。しかし、Automation Suite には、この作業を支援する共有ボリュームと Init コンテナー cert-trustor が含まれています。Init は、ポッド内でアプリ コンテナーより先に実行される特殊なコンテナーであり、そのジョブが完了するとすぐにそのライフサイクルが終了します。
次の例では、Orchestrator サービスは 1 つのポッドで実行されています。なお、1 つのポッドに複数のコンテナーを含めることができます。このポッドに、Cert-trustor という Init コンテナーを 1 つ以上挿入します。このコンテナーに、ルート証明書、中間証明書、リーフ証明書が含まれます。
/etc/pki/ca-trust/ca/source/anchors
です。
/etc/pki/ca-trust/ca/source/anchors
の場所にある共有ボリュームに証明書を追加するジョブを実行し、終了します。
証明書は、共有ボリュームを通じて Orchestrator サービスで利用できます。
Automation Suite のインストールの一環として、次の証明書が生成されます。
- 自己署名証明書。インストール時に生成され、3 か月間有効です。インストール後に、自己署名証明書をドメイン証明書に置き換える必要があります。「証明書を管理する」をご覧ください。
- Identity Server の証明書。認証で使用される JWT トークンに署名するために使われます。JWT トークンに署名するための証明書が提供されていない場合、Automation Suite は、現在設定されている TLS 証明書 (自己署名証明書またはユーザー提供の証明書) を使用します。有効期限は 90 日です。ID トークンに署名するための独自の証明書を持っている場合は、「証明書を管理する」の手順を使用して構成できます。
-
MongoDB の内部証明書。Cert Manager によって生成されます。バージョン 2021.10.3 以前の Automation Suite では、90 日間有効な MongoDB の内部証明書が提供されています。バージョン 2021.10.4 からは、証明書は 3 年間有効で、自動的に更新されます。
詳細については、「Apps ユーザー向けの MongoDB 証明書の手動更新方法」をご覧ください。
- 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
# For docker registry
kubectl -n docker-registry get secrets docker-registry-tls -o yaml
# For Argocd
argocd cert list --cert-type https