はじめに
2021年初に、Red Hatがstackroxを買収し、RHACS（Red Hat Advanced Cluster Security for Kubernetes）として製品化しました。ソフトウェア製品が何をしてくれるのか、どういった使い勝手なのかを学ぶ近道は、それを実際に使ってみることです。しかしOpenShiftで稼働させるには、用意するリソースや導入の手間などで、ある程度のハードルがあるのも確かです。
この記事では、開発用のシングルノードOpenShiftであるOpenShift Local上でRHACSを稼働させる方法を説明します。OpenShift Localは、ローカルコンピュータで使用できるとはいえ、一般的なノートPCで稼働させるには少々重いのが難点です。しかし、マルチノードのクラスターを立てるよりは遥かに簡単にOpenShift環境を用意できますし、クラスターの作り直しも非常に容易です。デフォルトでPVも用意されるので、RHACSのようなストレージを必要とするソフトウェアの導入も、あれこれと追加の作業が不要です。
色々と試し、おかしくなったら作り直しができるので、実際に使ってみる学習にはもってこいの環境であり、私のように「動かして理解する」者にとって非常に助かるツールの一つです。
用意するもの
Red Hat Advanced Container Security Product Trial Subscription
Red Hatは、60日間の製品使用が可能となるproduct trialサブスクリプションを提供しています。以下のURLで申し込んでおきましょう。
OpenShift Local用VM
OpenShift Localは、その名の通りローカルコンピュータ（手元のノートPCとか）で稼働させるOpenShift環境なのですが、最低のシステム要件でIAの物理CPUコアを4個必要とします。後述しますが、4物理コア（8vCPU）ではRHACSのPodがギリ起動しませんでした。OpenShift Local + RHACSで最低どの程度のリソースが必要となるかを確認するため、この記事ではVMwareを使用したVM上でOpenShift Localを稼働させました。VMを使うことは必須ではありませんが、今回は以下のリソースで試しました。
- vCPU 9
- Memory 44GBytes
- Local Storage 70GBytes
- VT-x/EPT enable
- Fedora 36 Workstation
OpenShift Local環境
上で用意したVMでOpenShift Local環境を稼働させます。OpenShift Localのインストール方法は、ここでは取り上げません。ただし、デフォルトの設定では用意したリソースを使いきれないので、crc startする前に以下の設定を実行する必要があります。
crc config cpu 9crc config memory 40960crc config disk-size 40
これがOpenShfit Local + RHACSが起動するギリギリのラインでした。もう少し積み増した方が安定します。CPUはオーバーコミット気味なので、VMのvCPUを2〜3足し、この設定を少し増やすと良いかもしれません。
RHACSのインストール
RHACSのインストールはマニュアル通りに進めれば特に難しい点はありません。Operatorインストールであれば、全てデフォルト設定でインストールは完了します。
また、qiitaにも手順を丁寧に解説した優れた記事が公開されているので、それを見ながら進めてください。記事はマルチノードOpenShiftを対象にしていますが、OpenShift Localにインストールする場合も手順は同じです。
1点補足すると、記事の手順ではScuredClusterデプロイの際に、Central Endpointを指定していますが、これはデフォルト値なのでブランクのままで構いません。
運用
運用といっても、目的はお試しなので本番運用とは異なり、開発環境で日々生じるであろう点について説明します。
クラスターの起動・終了
開発環境（デスクトップPCやノートブックPC）で稼働するクラスターは、使用するリソースがそれなりに大量であることや不特定多数のユーザにサービスを提供するわけでもないことから、いずれどこかのタイミングで停止させる必要があります。
OpenShift Localではクラスターの起動停止は容易なので（crc stopコマンドでクラスターの停止、crc startコマンドで起動）、クラスターを使用しない間は止める運用になるはずです。
この記事を書いた時点でのRHACS（バージョン3.72.1）では、crcコマンドによるクラスターの再起動により、正常に稼働しなくなるケースがあるため、その原因と対応方法について説明します。
クラスター再起動時の、scanner-db Podの挙動
クラスターを再起動した後、stackroxプロジェクトPodの一部がReadyにならないことがあります。
$ oc get pod -n stackrox
NAME READY STATUS RESTARTS AGE
admission-control-7845ff6d77-8djc9 1/1 Running 17 4d5h
admission-control-7845ff6d77-jlv9p 1/1 Running 15 4d5h
admission-control-7845ff6d77-klkkx 1/1 Running 14 4d5h
central-77d4ffbd5d-z9cn4 1/1 Running 16 4d5h
collector-l6xg5 2/2 Running 25 4d5h
scanner-687d949cbf-8rz4m 0/1 Running 20 4d5h
scanner-687d949cbf-p86tb 0/1 Running 20 4d5h
scanner-687d949cbf-vwdzm 0/1 Running 21 4d5h
scanner-db-6f7547564d-r8z8j 0/1 Init:0/1 1 37m
sensor-85bdcc8c6b-59ksz 1/1 Running 16 4d5h
scanner-db PodのSTATUSがInit:0/1のまま、起動しません。そのため、scanner PodもDB接続待ちでREADYが0/1から先に進みません。scanner-db Podは、Initコンテナとして、init-dbを実行しているので、そのログを確認してみましょう。
$ oc logs scanner-db-6f7547564d-r8z8j -c init-db -n stackrox
PostgreSQL Database directory appears to contain a database; Skipping initialization
2022-11-08 07:35:33.031 UTC [1] LOG: starting PostgreSQL 12.11 on x86_64-redhat-linux-gnu, compiled by gcc (GCC) 8.5.0 20210514 (Red Hat 8.5.0-10), 64-bit
2022-11-08 07:35:33.033 UTC [1] LOG: listening on IPv4 address "0.0.0.0", port 5432
2022-11-08 07:35:33.033 UTC [1] LOG: listening on IPv6 address "::", port 5432
2022-11-08 07:35:33.037 UTC [1] LOG: listening on Unix socket "/var/run/postgresql/.s.PGSQL.5432"
2022-11-08 07:35:33.042 UTC [1] LOG: listening on Unix socket "/tmp/.s.PGSQL.5432"
2022-11-08 07:35:33.126 UTC [14] LOG: database system was interrupted; last known up at 2022-11-08 07:16:16 UTC
2022-11-08 07:35:33.400 UTC [14] LOG: database system was not properly shut down; automatic recovery in progress
2022-11-08 07:35:33.404 UTC [14] LOG: redo starts at 0/4D6907B8
2022-11-08 07:35:33.404 UTC [14] LOG: invalid record length at 0/4D690910: wanted 24, got 0
2022-11-08 07:35:33.404 UTC [14] LOG: redo done at 0/4D6908D8
2022-11-08 07:35:33.439 UTC [1] LOG: database system is ready to accept connections
おそらく、crc stopによるPod停止方法が適切ではないのでしょう。PostgreSQLのautomatic recoveryが動いています。問題は、そのrecoveryを行うinit-dbコンテナが終了しないため、後続の処理が進まないのでしょう。database system is ready to accept connectionsメッセージが確認できたら、scanner-db Podのdeleteによる再起動で、この状態から回復します。
$ oc delete pod scanner-db-6f7547564d-r8z8j -n stackrox
pod "scanner-db-6f7547564d-r8z8j" deleted
$
$ oc get pod -n stackrox
NAME READY STATUS RESTARTS AGE
admission-control-7845ff6d77-8djc9 1/1 Running 17 4d5h
admission-control-7845ff6d77-jlv9p 1/1 Running 15 4d5h
admission-control-7845ff6d77-klkkx 1/1 Running 14 4d5h
central-77d4ffbd5d-z9cn4 1/1 Running 16 4d5h
collector-l6xg5 2/2 Running 25 4d5h
scanner-687d949cbf-8rz4m 1/1 Running 20 4d5h
scanner-687d949cbf-p86tb 1/1 Running 20 4d5h
scanner-687d949cbf-vwdzm 1/1 Running 21 4d5h
scanner-db-6f7547564d-4d8rn 1/1 Running 0 84s
sensor-85bdcc8c6b-59ksz 1/1 Running 16 4d5h
init-dbのログを確認すると、正常に処理が行われ最後に処理が停止していることがわかります。
$ oc logs scanner-db-6f7547564d-4d8rn -c init-db -n stackrox
The files belonging to this database system will be owned by user "postgres".
This user must also own the server process.
（途中省略）
waiting for server to shut down....2022-11-08 07:47:50.241 UTC [32] LOG: received fast shutdown request
2022-11-08 07:47:50.245 UTC [32] LOG: aborting any active transactions
2022-11-08 07:47:50.247 UTC [32] LOG: background worker "logical replication launcher" (PID 39) exited with exit code 1
2022-11-08 07:47:50.247 UTC [34] LOG: shutting down
2022-11-08 07:47:50.311 UTC [32] LOG: database system is shut down
done
server stopped
PostgreSQL init process complete; ready for start up.
このDBおよびscanner Podは、イメージスキャンと関連がありそうなので、それ以外の機能を使うのであれば、DBとscannerが起動していなくても良いかもしれません。
はじめからやり直し（Central再作成）
色々設定の変更やコマンドの実行を試すうちに、最初の状態に戻して再度試してみたくなることがあります。OpenShift Localはクラスターの再作成が容易（crc deleteしてから、crc start）なので、クラスターから作り直しても良いでしょう。
しかし、やり直したい変更がRHACSの中に閉じているのであれば、クラスターを再作成して再度RHACSをインストールするよりも、Centralだけを再作成すれば十分な場合もあります。
Central削除
Centralの削除は、デプロイの手順と逆に進めます。つまり
- SecuredClusterの削除
- Centralの削除
- stackroxプロジェクトの削除
です。実際には、oc delete project stackroxだけで良いと思います。依存関係に従い、stackroxプロジェクトがなくなるまで少し時間が必要ですが、再度stackroxプロジェクトを作成できたら、Centralの作成に進めます。
Central作成
作成の手順は変わりません。初回のインストールと同じことを繰り返すだけです。ただし、手順の中でRHACSダッシュボードを開きますが、その際にLoadingが表示されたまま、先に進まないことがあります。
この場合は、ブラウザのリロードを行うと、自己証明書の警告画面に戻るので、そこからは通常の手順で進めます。
おわりに
RHACSの動作を確かめるために、OpenShift LocalでRHACSを使用する際に必要となるものと、稼働させるための注意点について説明しました。
コンテナオーケストレータを使ってアプリケーションをコンテナとして稼働させるのが一般的になるに伴い、利用者の関心はコンテナをどう使うかから、セキュリティをどう確保するかに移っているように思います。少々必要リソースのハードルは高いものの、個人で用意可能な環境を使用して動作を試せるのは、ソフトウェアの機能を理解するにはとても有難いです。本記事の中では、RHACSの具体的な機能やその使い方については触れていませんが、こうした環境を試し、理解し、セキュアなコンテナ環境を普及させるための一助となれば幸いです。