- 概要
- 要件
- インストール前
- インストール
- インストール後
- 移行とアップグレード
- 監視とアラート機能
- クラスターの管理
- 製品固有の設定
- トラブルシューティング
- Azure Government への接続に失敗したため、バックアップのセットアップが機能しない
- カスタム ノード taint を有効化すると uipath 名前空間のポッドがスタックする
- プロキシ設定がある場合に Automation Hub と Apps を起動できない
- Velero のバックアップが FailedValidation エラーで失敗する
- 外部シークレットのトラブルシューティング
- Temporal as a Service のトラブルシューティング
- TLS 証明書の検証が有効化されていると、AI Center と Document Understanding ポッドの起動に失敗する
- TLS 証明書の検証エラー
- Fluentd では、IPv6 環境ではログはエクスポートされません
- デスクトップ版の Studio では Integration Service のコネクタとアクティビティを読み込めない
- 手動による ArgoCD ネットワーク ポリシーの軽減策 (GHSA-47m3-95c7-g2g8)
- uipathctl で作成されたワークロードのリソース要求と制限を設定する
EKS/AKS の Automation Suite のセキュリティ機能、FIPS 140-2 のサポート、ネットワーク ポリシー。
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 の |
|
|
| コンテナーで使用する AppArmor プロファイルの許可リストを設定します。 PodSecurityPolicy に適用される特定の注釈に対応します。 |
|
|
| コンテナーでの Linux の機能を制御します。 PodSecurityPolicy の |
|
|
| FlexVolume ドライバーの許可リストを制御します。 PodSecurityPolicy の |
|
|
|
|
| |
| ポッドのボリュームを所有する FSGroup の割り当てを制御します。 PodSecurityPolicy の |
|
|
| ホスト ファイルシステムの使用を制御します。 PodSecurityPolicy の |
|
|
| ポッド コンテナーでホストの PID 名前空間と IPC 名前空間を共有することを禁止します。 PodSecurityPolicy の |
|
|
| ポッド コンテナーによるホスト ネットワーク名前空間の使用を制御します。 |
|
|
| 特権モードを有効化するコンテナーの機能を制御します。 PodSecurityPolicy の |
|
|
| コンテナーで許可される PodSecurityPolicy の |
|
|
| ポッド コンテナーは読み取り専用のルート ファイル システムを使用する必要があります。 |
|
|
| コンテナーで使用する seccomp プロファイルを制御します。 PodSecurityPolicy の |
|
|
| ポッド コンテナーの seLinuxOptions 設定の許可リストを定義します。 |
|
|
| コンテナーおよび一部のボリュームのユーザー ID とグループ ID を制御します。 |
|
|
| マウント可能なボリュームの種類を、ユーザーが指定したものに制限します。 |
|
|
名前空間 airflow は、Process Mining をインストールする場合にのみ必要です。
その他の OPA ポリシー
| ポリシー | 適用されるアクション | 除外される名前空間/イメージ |
|---|---|---|
|
|
|
|
| コンテナー イメージは指定したリストの文字列で始まる必要があります。 |
|
|
|
| N/A | |
| 種類が LoadBalancer であるサービスをすべて禁止します。 |
|
|
| NodePort のすべてのサービスを禁止します。 |
|
|
| ユーザーが空白またはワイルドカード (*) のホスト名を持つ Ingress を作成できないようにします。このようなホスト名を使用すると、アクセス権がなくてもクラスター内の他のサービスのトラフィックをインターセプトできるためです。 |
|
|
| コンテナーにメモリと CPU の制限を設定する必要があります。制限値を、指定した最大値の範囲内に制限します。 |
|
|
| コンテナーがメモリと CPU の要件セットを含むよう要求します。要求が指定した最大値の範囲内となるよう強制します。 |
|
|
| 要求に対するコンテナー リソース制限の最大比率を設定します。 |
|
|
| コンテナーに、定義済みのリソースを設定する必要があります。 |
|
|
| ClusterRole リソースと Role リソースを |
| N/A |
| コンテナー イメージに、指定したリストのイメージ タグとは異なるイメージ タグを付ける必要があります。 |
| N/A |
| コンテナーにエフェメラル ストレージの制限を設定する必要があります。また、その制限値を、指定した最大値の範囲内に制限します。 |
|
|
|
| N/A | |
| Ingress リソースを HTTPS 専用にする必要があります。 Ingress リソースに デフォルトでは、有効な TLS {} 設定が必要です。 |
|
|
| コンテナー イメージにダイジェストを含める必要があります。 |
|
|
| ポッド上で抽象化されたリソースでサービス アカウントの更新をブロックします。このポリシーは監査モードでは無視されます。 |
| N/A |
|
|
| |
| ポッドが Readiness Probe および/または Liveness Probe を持つ必要があります。 |
|
|
| 使用する場合はストレージ クラスを指定する必要があります。 |
| N/A |
| すべての Ingress ルール ホストが一意である必要があります。 |
| N/A |
| サービスは名前空間内で一意のセレクターを使用する必要があります。キーと値が同一のセレクターは同じと見なされます。複数のセレクターで 1 つのキー/値のペアを共有できます。ただし、セレクター間で異なるキー/値のペアが 1 つ以上あることが条件です。 |
| N/A |
- 名前空間
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 チャート を反映させてください。
Kubernetes ネットワーク ポリシーは CNI プラグインによって適用されます。Amazon VPC CNI などの一部の CNI では、既定ではネットワークポリシーが適用されません。その場合、UiPath が提供するネットワーク ポリシーは作成されますが、効果はありません。クラスターでネットワーク ポリシーの適用が有効化されていることを確認します。手順については、CNI の公式ドキュメントをご覧ください。
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 の要件」をご覧ください。
- Insights は FIPS 140-2 ではサポートされていないため、無効化されていることを確認してください。Insights を使用する必要がある場合は、専用の非 FIPS ノードにデプロイできます。詳しくは、「 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 の要件」をご覧ください。
- Insights を以前に有効化した場合は、FIPS 140-2 ではサポートされていないため、無効化する必要があります。Insights を使用する必要がある場合は、専用の非 FIPS ノードにデプロイできます。詳しくは、「 How to deploy Insights in a FIPS enabled cluster」をご覧ください。インストール後に製品を無効化する方法について詳しくは、「 製品を管理する」をご覧ください。
- マシンを再起動し、FIPS 140-2 が正常に有効化されたかどうかを確認します。
uipathctlインストーラーを再実行します。