- 概要
- 要件
- インストール前
- インストール
- インストール後
- 移行とアップグレード
- Automation Suite をアップグレードする
- スタンドアロン製品を Automation Suite に移行する
- 手順 1: スタンドアロンの製品データベースを復元する
- 手順 2: 復元した製品データベースのスキーマを更新する
- 手順 3: Identity 組織データをスタンドアロンから Automation Suite に移動する
- 手順 4: Automation Suite のプラットフォーム データベースをバックアップする
- 手順 5: 組織を Automation Suite にマージする
- 手順 6: 以降済みの製品の接続文字列を更新する
- 手順 7: スタンドアロンの Orchestrator を移行する
- 手順 8: スタンドアロンの Insights を移行する
- 手順 9: スタンドアロンの Test Manager を移行する
- 手順 10: 既定のテナントを削除する
- 単一テナントの移行を実行する
- Automation Suite クラスター間を移行する
- EKS/AKS の Automation Suite から OpenShift の Automation Suite に移行する
- 監視とアラート機能
- クラスターの管理
- 製品固有の設定
- トラブルシューティング

EKS/AKS の Automation Suite のインストール ガイド
セキュリティとコンプライアンス
UiPath® サービスのセキュリティ コンテキスト
このセクションでは、UiPath® サービスのセキュリティ コンテキストについて詳しく説明します。
すべての UiPath® サービスは、 spec セクションで定義されたセキュリティ コンテキストを使用して構成されます。
以下のサンプルは、UiPath® サービスの一般的な構成を示しています。
spec:
securityContext:
runAsNonRoot: true
runAsUser: 1000
runAsGroup: 1000
fsGroup: 1000
containers:
- securityContext:
allowPrivilegeEscalation: false
readOnlyRootFilesystem: true
capabilities:
drop: ["ALL"]
hostPID: false
hostNetwork: false
spec:
securityContext:
runAsNonRoot: true
runAsUser: 1000
runAsGroup: 1000
fsGroup: 1000
containers:
- securityContext:
allowPrivilegeEscalation: false
readOnlyRootFilesystem: true
capabilities:
drop: ["ALL"]
hostPID: false
hostNetwork: false
一部の UiPath® サービスでは、一般的なセキュリティ コンテキストの構成とは異なる例外があります。
connector-builder-setup-jobサービスのケースでは、readOnlyRootFilesystemパラメーターの値はfalseです。
場合によっては、環境によっては、ユーザー ID とグループ ID が 1000 以上になることがあります。 ユーザー ID とグループ ID は、必ずセキュリティ原則と組織のセキュリティ ガイドラインに従って構成してください。
Gatekeeper と OPA ポリシー
Automation Suite には、Gatekeeper と OPA ポリシーが事前に構成されています。独自の Gatekeeper コンポーネントと OPA ポリシーを使用する場合は、Automation Suite のインストール時にこれらのコンポーネントをスキップできます。詳しくは、Automation Suite のスタックをご覧ください。この場合、OPA ポリシーと、Automation Suite のインストールと実行に必要な例外を確認してください。
既定では、これらのポリシーは UiPath® 名前空間 (-uipath、uipath-installer、uipath-infra、airflow、および argocd でのみ実行されます。
OPA ポリシー
表を展開
| ポリシー | 適用されるアクション | 除外される名前空間/イメージ |
|---|---|---|
ルート権限へのエスカレーションの制限を制御します。PodSecurityPolicy の allowPrivilegeEscalation フィールドに対応します。 |
|
|
| コンテナーで使用する AppArmor プロファイルの許可リストを設定します。PodSecurityPolicy に適用される特定の注釈に対応します。 |
|
|
コンテナーでの Linux の機能を制御します。PodSecurityPolicy の allowedCapabilities フィールドと requiredDropCapabilities フィールドに対応します。 |
|
|
FlexVolume ドライバーの許可リストを制御します。PodSecurityPolicy の allowedFlexVolumes フィールドに対応します。 |
|
|
|
|
| |
ポッドのボリュームを所有する FSGroup の割り当てを制御します。PodSecurityPolicy の fsGroup フィールドに対応します。 |
|
|
ホスト ファイルシステムの使用を制御します。PodSecurityPolicy の allowedHostPaths フィールドに対応します。 |
|
|
ポッド コンテナーでホストの PID 名前空間と IPC 名前空間を共有することを禁止します。PodSecurityPolicy の hostPID フィールドと hostIPC フィールドに対応します。 |
|
|
| ポッド コンテナーによるホスト ネットワーク名前空間の使用を制御します。 |
|
|
特権モードを有効化するコンテナーの機能を制御します。PodSecurityPolicy の privileged フィールドに対応します。 |
|
|
コンテナーで許可される procMount の種類を制御します。PodSecurityPolicy の allowedProcMountTypes フィールドに対応します。 |
|
|
| ポッド コンテナーは読み取り専用のルート ファイル システムを使用する必要があります。 |
|
|
コンテナーで使用する seccomp プロファイルを制御します。PodSecurityPolicy の seccomp.security.alpha.kubernetes.io/allowedProfileNames 注釈に対応します。 |
|
|
| ポッド コンテナーの seLinuxOptions 設定の許可リストを定義します。 |
|
|
| コンテナーおよび一部のボリュームのユーザー ID とグループ ID を制御します。 |
|
|
| マウント可能なボリュームの種類を、ユーザーが指定したものに制限します。 |
|
|
- 名前空間
dapr-systemは、Process Mining と Task Mining をインストールする場合にのみ必要です。 - 名前空間
airflowは、Process Mining をインストールする場合にのみ必要です。
その他の OPA ポリシー
表を展開
| ポリシー | 適用されるアクション | 除外される名前空間/イメージ |
|---|---|---|
automountServiceAccountToken を有効化するポッドの機能を制御します。 |
|
|
| コンテナー イメージは指定したリストの文字列で始まる必要があります。 |
|
|
|
| N/A | |
| 種類が LoadBalancer であるサービスをすべて禁止します。 |
|
|
| NodePort のすべてのサービスを禁止します。 |
|
|
| ユーザーが空白またはワイルドカード (*) のホスト名を持つ Ingress を作成できないようにします。このようなホスト名を使用すると、アクセス権がなくてもクラスター内の他のサービスのトラフィックをインターセプトできるためです。 |
|
|
| コンテナーにメモリと CPU の制限を設定する必要があります。制限値を、指定した最大値の範囲内に制限します。 |
|
|
| コンテナーがメモリと CPU の要件セットを含むよう要求します。要求が指定した最大値の範囲内となるよう強制します。 |
|
|
| 要求に対するコンテナー リソース制限の最大比率を設定します。 |
|
|
| コンテナーに、定義済みのリソースを設定する必要があります。 |
|
|
ClusterRole リソースと Role リソースを system:anonymous ユーザーと system:unauthenticated グループに関連付けることを禁止します。 |
| N/A |
| コンテナー イメージに、指定したリストのイメージ タグとは異なるイメージ タグを付ける必要があります。 |
| N/A |
| コンテナーにエフェメラル ストレージの制限を設定する必要があります。また、その制限値を、指定した最大値の範囲内に制限します。 |
|
|
|
| N/A | |
Ingress リソースを HTTPS 専用にする必要があります。Ingress リソースに kubernetes.io/ingress.allow-http 注釈を含め、false に設定する必要があります。既定では、TLS {} の有効な設定が必要です。tlsOptional パラメーターを true に設定すると、この設定を任意にすることができます。 |
|
|
| コンテナー イメージにダイジェストを含める必要があります。 |
|
|
| ポッド上で抽象化されたリソースでサービス アカウントの更新をブロックします。このポリシーは監査モードでは無視されます。 |
| N/A |
|
|
| |
| ポッドが Readiness Probe および/または Liveness Probe を持つ必要があります。 |
|
|
| 使用する場合はストレージ クラスを指定する必要があります。 |
| N/A |
| すべての Ingress ルール ホストが一意である必要があります。 |
| N/A |
| サービスは名前空間内で一意のセレクターを使用する必要があります。キーと値が同一のセレクターは同じと見なされます。複数のセレクターで 1 つのキー/値のペアを共有できます。ただし、セレクター間で異なるキー/値のペアが 1 つ以上あることが条件です。 |
| N/A |
- 名前空間
dapr-systemは、Process Mining と Task Mining をインストールする場合にのみ必要です。 - 名前空間
airflowは、Process Mining をインストールする場合にのみ必要です。 prereq**は前提条件の実行または健全性チェックの間に作成される一時的な名前空間です。完了するとこの名前空間は自己削除されます。
ネットワーク ポリシー
Automation Suite には、最小特権ネットワーク アクセスの原則に従うための標準の Kubernetes ネットワーク ポリシーが事前に構成されています。UiPath が提供するネットワーク ポリシーのインストールをスキップするには、input.json の exclude components リストに network-policies を追加します。任意のコンポーネントの詳細については、Automation Suite のスタックをご覧ください。
Automation Suite は、<uipath> 名前空間との間で、この名前空間内のネットワークを適用します。 独自のネットワーク ポリシーを利用する場合や、カスタム CNI (Cilium Enterprise や Calico Tigera Enterprise など) を使用している場合は、ポリシーを更新して network-policies Helm チャート を反映させてください。
Automation Suite の network-policies Helm チャートは、次のコマンドを使用して確認できます。
- 以下のコマンドでは、
<automation-suite-version>の部分を現在の Automation Suite のバージョンで置換する必要があります。 - Helm チャートを抽出するには、このファイルを解凍する必要があります。
helm pull oci://registry.uipath.com/helm/network-policies --version <automation-suite-version>
helm pull oci://registry.uipath.com/helm/network-policies --version <automation-suite-version>
クラスターの特権の要件
管理ノードで uipathctl Automation Suite を専用クラスターにインストールおよび管理するには、クラスター管理者のアクセス権が必要です。Istio (ルーティング/サービス メッシュ) や ArgoCD (デプロイとアプリケーション ライフサイクル管理) などの Automation Suite のシステム レベルのコンポーネント、および Automation Suite 関連の名前空間の作成には、このレベルのアクセス権が必要です。共有クラスターの場合、管理者権限は必要ありません。
FIPS 140-2
Federal Information Processing Standards 140-2 (FIPS 140-2) は、暗号化モジュールの有効性を検証するセキュリティ標準です。
の Automation Suite は、FIPS 140-2 が有効化されたマシンで実行できます。
以下のシナリオでは、Automation Suite をインストールするマシンで FIPS 140-2 を有効化できます。
- Automation Suite のクリーン インストールを実行する前に、FIPS 140-2 を有効化します。このシナリオは、EKS の Automation Suite と AKS の Automation Suite のどちらにも当てはまります。詳しくは、「 新規インストール用に FIPS 140-2 を有効化する」をご覧ください。
- FIPS-140-2 が無効化されているマシンで Automation Suite のインストールを実行した後は、FIPS 140-2 を有効化してください。詳しくは、「 既存のインストールで FIPS 140-2 を有効化する」を参照してください。
注:
このシナリオは、AKS の Automation Suite にのみ適用されます。EKS の Automation Suite で FIPS-140-2 を無効にした状態で Automation Suite のインストールを完了した場合、FIPS 140-2 を有効化できません。
新規インストールで FIPS 140-2 を有効化する
Automation Suite の新規インストールを実行する予定のマシンで FIPS 140-2 を有効化するには、次の手順を実行します。
- Automation Suite のインストールを開始する前に、お使いのマシンで FIPS 140-2 を有効化します。
- このガイドのインストール手順に従って、Automation Suite のインストールを実行します。
注:
- FIPS 140-2 が有効化されたマシンに AI Center をインストールし、Microsoft SQL Server も使用する場合は、追加の構成が必要です。詳しくは、「AI Center のための SQL の要件」をご覧ください。
- Make sure Insights and Integration Service are disabled, as they are not supported on FIPS 140-2. If you need to use Insights, you can deploy it on a dedicated non-FIPS node. For details, refer to How to deploy Insights in a FIPS-enabled cluster.
input.jsonファイルでfips_enabled_nodesフラグをtrueに設定します。- 証明書が FIPS 140-2 に対応していることを確認します。
注:
Automation Suite では、既定で FIPS 140-2 対応の自己署名証明書が生成されます。この証明書の有効期限は、選択した Automation Suite インストールの種類によって異なります。
これらの自己署名証明書を、インストール時に CA によって発行された証明書に置き換えることを強くお勧めします。FIPS 140-2 が有効化されたマシンで Automation Suite を使用するには、新たに提供される証明書が FIPS 140-2 に対応している必要があります。RHEL でサポートされる有効な暗号のリストについては、 RHEL のドキュメントをご覧ください。
独自の FIPS 140-2 準拠のトークン署名および TLS 証明書を追加する方法について詳しくは、「証明書の設定」をご覧ください。
- EKS の Automation Suite の場合は、RDS 証明書バンドルのパスを指定する必要があります。RDS 証明書バンドルのリージョン固有のダウンロード リンクは、 AWS のドキュメントで確認できます。次の例に示すように、
input.json構成ファイル内の RDS 証明書バンドルpemファイルを必ず更新してください。{ ... "additional_ca_certs": "certificates/rds-aws-bundle.pem", ... }{ ... "additional_ca_certs": "certificates/rds-aws-bundle.pem", ... }
既存のインストールでの FIPS 140-2 の有効化
FIPS 140-2 を無効にした Automation Suite をインストールし、同じマシンでこのセキュリティ標準を有効化することができます。 これは、Automation Suite の新しいバージョンにアップグレードする場合にも可能です。
現在、AKS の Automation Suite の既存のインストールでは FIPS 140-2 を有効化できますが、EKS の Automation Suite の既存のインストールでは有効化できません。EKS の Automation Suite に対して FIPS 140-2 を有効化できるのは、Automation Suite のクリーン インストールを実行する前にのみです。詳しくは、「 新規インストール用に FIPS 140-2 を有効化する」をご覧ください。
Automation Suite のインストールを既に実行したマシンで FIPS 140-2 を有効化するには、次の手順を実行します。
- FIPS 140-2 が無効化されたマシンで、通常の Automation Suite のインストールまたはアップグレード操作を実行します。
- すべてのマシンで FIPS 140-2 を有効化します。
- 証明書が FIPS 140-2 に対応していることを確認します。
注:
FIPS 140-2 が有効化されたマシンで Automation Suite を使用するには、証明書を CA によって署名された新しい FIPS 140-2 対応の証明書に置き換える必要があります。RHEL でサポートされる有効な暗号のリストについては、RHEL のドキュメントをご覧ください。 独自の FIPS 140-2 準拠のトークン署名および TLS 証明書を追加する方法について詳しくは、「証明書の設定」をご覧ください。 証明書の詳細については、以下のページをご覧ください。
- 製品の選択が FIPS 140-2 の要件に沿っていることを確認します。
- FIPS 140-2 が有効化されたマシンに AI Center をインストールし、Microsoft SQL Server も使用する場合は、追加の構成が必要です。詳しくは、「AI Center のための SQL の要件」をご覧ください。
- If you previously enabled Insights or Integration Service, you must disable them as they are not supported on FIPS 140-2. If you need to use Insights, you can deploy it on a dedicated non-FIPS node. For details, refer to How to deploy Insights in a FIPS-enabled cluster. For details on how to disable products post-installation, see Managing products.
- マシンを再起動し、FIPS 140-2 が正常に有効化されたかどうかを確認します。
uipathctlインストーラーを再実行します。