2.2. Red Hat OpenShift での RHACS の前提条件
RHACS for OpenShift Container Platform または他の OCP 互換のサポートされる Kubernetes プラットフォームをインストールする前に、前提条件を満たしていることを確認してください。
2.2.1. 一般要件
RHACS には、インストールする前に満たす必要のあるシステム要件がいくつかあります。
次の場所に Red Hat Cluster Security for Kubernetes をインストールしないでください。
- Amazon Elastic File System (Amazon EFS)。代わりに、デフォルトの gp2 ボリュームタイプで Amazon Elastic Block Store (Amazon EBS) を使用してください。
- Streaming SIMD Extensions (SSE) 4.2 命令セットを備えていない古い CPU。たとえば、Sandy Bridge より古い Intel プロセッサー、および Bulldozer より古い AMD プロセッサー。(これらのプロセッサーは 2011 年にリリースされました。)
Red Hat Advanced Cluster Security for Kubernetes をインストールするには、次のものが必要です。
- OpenShift Container Platform バージョン 4.10 以降。サポートされているセルフマネージドおよびマネージド OpenShift Container Platform の詳細は、Red Hat Advanced Cluster Security for Kubernetes サポートポリシー を参照してください。
サポートされているオペレーティングシステムを備えたクラスターノード。
- Red Hat Enterprise Linux CoreOS (RHCOS), Red Hat Enterprise Linux (RHEL).
プロセッサーとメモリー :2 つの CPU コアと少なくとも 3GiB の RAM。
注記Central をデプロイするには、4 つ以上のコアを備えたマシンタイプを使用し、スケジューリングポリシーを適用して、そのようなノードで Central を起動します。
アーキテクチャー: AMD64、ppc64le、または s390x。
注記ppc64le または s390x アーキテクチャーの場合、RHACS Secured クラスターサービスは IBM Power、IBM zSystems、および IBM® LinuxONE クラスターにのみインストールできます。現時点では、Central はサポートされていません。
永続ボリューム要求 (PVC) を使用した永続ストレージ。
重要Red Hat Advanced Cluster Security for Kubernetes で Ceph FS ストレージを使用しないでください。Red Hat は、Red Hat Advanced Cluster Security for Kubernetes に RBD ブロックモード PVC を使用することをお勧めします。
- 最高のパフォーマンスを得るには、ソリッドステートドライブ (SSD) を使用してください。ただし、SSD を使用できない場合は、別のタイプのストレージを使用できます。
Helm チャートを使用してインストールするには:
-
Helm チャートを使用して Red Hat Advanced Cluster Security for Kubernetes をインストールまたは設定する場合は、Helm コマンドラインインターフェイス (CLI)v3.2 以降が必要です。
helm version
コマンドを使用して、インストールした Helm のバージョンを確認する。 -
Red Hat OpenShift CLI (
oc
)。 -
Red Hat Container Registry へのアクセスがあること。
registry.redhat.io
からイメージをダウンロードする方法は、Red Hat コンテナーレジストリーの認証 を参照してください。
2.2.2. Central をインストールするための前提条件
Central と呼ばれるコンテナー化されたサービスは API インタラクションとユーザーインターフェイス (ポータル) アクセスを処理し、Central DB (PostgreSQL 13) と呼ばれるコンテナー化されたサービスはデータの永続性を処理します。
Central と Central DB の両方に永続ストレージが必要です。
永続ボリュームクレーム (PVC) を使用してストレージを提供できます。
注記hostPath ボリュームをストレージに使用できるのは、すべてのホスト (またはホストのグループ) が NFS 共有やストレージアプライアンスなどの共有ファイルシステムをマウントしている場合のみです。それ以外の場合、データは単一のノードにのみ保存されます。Red Hat は、hostPath ボリュームの使用を推奨していません。
- 最高のパフォーマンスを得るには、ソリッドステートドライブ (SSD) を使用してください。ただし、SSD を使用できない場合は、別のタイプのストレージを使用できます。
Web プロキシーまたはファイアウォールを使用する場合は、
definitions.stackrox.io
ドメインとcollector-modules.stackrox.io
ドメインのトラフィックを許可するバイパスルールを設定し、Red Hat Advanced Cluster Security for Kubernetes が Web プロキシーまたはファイアウォールを信頼できるようにする必要があります。そうしないと、脆弱性定義とカーネルサポートパッケージの更新が失敗します。Red Hat Advanced Cluster Security for Kubernetes には、以下へのアクセスが必要です。
-
definitions.stackrox.io では
、更新された脆弱性定義がダウンロードできます。脆弱性定義の更新により、Red Hat Advanced Cluster Security for Kubernetes は、新しい脆弱性が発見されたとき、または追加のデータソースが追加されたときに、最新の脆弱性データを維持できます。 -
更新されたカーネルサポートパッケージをダウンロードするには、
collector-modules.stackrox.io
を使用します。更新されたカーネルサポートパッケージにより、Red Hat Advanced Cluster Security for Kubernetes は、最新のオペレーティングシステムをモニターし、コンテナー内で実行されているネットワークトラフィックとプロセスに関するデータを収集できます。これらの更新がないと、クラスターに新しいノードを追加したり、ノードのオペレーティングシステムを更新したりすると、Red Hat Advanced Cluster Security for Kubernetes がコンテナーのモニターに失敗する可能性があります。
-
セキュリティー上の理由から、管理アクセスが制限されたクラスターに Central をデプロイする必要があります。
メモリーとストレージの要件
次の表に、Central のインストールと実行に必要な最小メモリーとストレージの値を示します。
Central | CPU | メモリー | ストレージ |
---|---|---|---|
要求 | 1.5 コア | 4 GiB | 100 GiB |
制限 | 4 コア | 8 GiB | 100 GiB |
Central DB | CPU | メモリー | ストレージ |
---|---|---|---|
要求 | 4 コア | 8 GiB | 100 GiB |
制限 | 8 コア | 16 GiB | 100 GiB |
サイジングガイドライン
クラスター内のノードの数に応じて、次のコンピュートリソースとストレージ値を使用します。
ノード | デプロイメント | Central CPU | Central Memory | Central Storage |
---|---|---|---|---|
最大 100 | 最大 1000 | 2 コア | 4 GiB | 100 GiB |
最大 500 | 最大 2000 | 4 コア | 8 GiB | 100 GiB |
500 以上 | 2000 以上 | 8 コア | 12 - 16 GiB | 100 - 200 GiB |
ノード | デプロイメント | Central DB CPU | Central DB Memory | Central DB Storage |
---|---|---|---|---|
最大 100 | 最大 1000 | 2 コア | 4 GiB | 100 GiB |
最大 500 | 最大 2000 | 4 コア | 8 GiB | 100 GiB |
500 以上 | 2000 以上 | 8 コア | 12 - 16 GiB | 100 - 200 GiB |
2.2.3. Scanner をインストールするための前提条件
Red Hat Advanced Cluster Security for Kubernetes には、Scanner と呼ばれるイメージ脆弱性 Scanner が含まれています。このサービスは、イメージレジストリーに統合されているスキャナーでスキャンされていないイメージをスキャンします。
メモリーとストレージの要件
Scanner | CPU | Memory |
---|---|---|
要求 | 1.2 コア | 2700 MiB |
制限 | 5 コア | 8000 MiB |
2.2.4. Sensor をインストールするための前提条件
Sensor は、Kubernetes および OpenShift Container Platform クラスターをモニターします。これらのサービスは現在、単一のデプロイメントでデプロイされ、Kubernetes API とのインタラクションを処理し、Collector と連携しています。
メモリーとストレージの要件
Sensor | CPU | Memory |
---|---|---|
要求 | 2 コア | 4 GiB |
制限 | 4 コア | 8 GiB |
2.2.5. Admission コントローラーをインストールするための前提条件
Admission Controller は、ユーザーが設定したポリシーに違反するワークロードを作成するのを防ぎます。
メモリーとストレージの要件
デフォルトでは、アドミッションコントロールサービスは 3 つのレプリカを実行します。次の表に、各レプリカのリクエストと制限を示します。
受付コントローラー | CPU | Memory |
---|---|---|
要求 | .05 コア | 100 MiB |
制限 | .5 コア | 500 MiB |
2.2.6. Collector をインストールするための前提条件
Collector は、セキュアなクラスター内の各ノードのランタイムアクティビティーを監視します。Sensor に接続してこの情報をレポートします。
Unified Extensible Firmware Interface (UEFI) があり、Secure Boot が有効になっているシステムに Collector をインストールするには、カーネルモジュールが署名されておらず、UEFI ファームウェアが署名されていないパッケージをロードできないため、eBPF プローブを使用する必要があります。Collector は、開始時に Secure Boot ステータスを識別し、必要に応じて eBPF プローブに切り替えます。
メモリーとストレージの要件
Collector | CPU | Memory |
---|---|---|
要求 | .05 コア | 320 MiB |
制限 | .75 コア | 1 GiB |
Collector は変更可能なイメージタグ (<version>-latest
) を使用するため、新しい Linux カーネルバージョンのサポートをより簡単に取得できます。コード、既存のカーネルモジュール、またはイメージ更新用の eBPF プログラムに変更はありません。更新では、最初のリリース後に公開された新しいカーネルバージョンをサポートする単一のイメージレイヤーのみが追加されます。