
multi-juicer v10.3.0
セキュリティトレーニングやCapture The Flag(CTF)のために、複数のJuice Shopインスタンスをホストおよび管理します。
OWASP Juice Shop を使った CTF やセキュリティトレーニングの実施は、通常かなり厄介です。Juice Shop はそもそも複数ユーザーによる同時利用を想定していません。 全員に自分のマシンで Juice Shop を起動する方法を教えることも可能ではありますが、貴重な時間をあまりに多く奪ってしまいます。
MultiJuicer は、中央の kubernetes クラスタ上で参加者ごとに個別の Juice Shop インスタンスを実行する機能を提供し、ローカルに Juice Shop インスタンスを用意することなくイベントを開催できるようにします。
主な機能:
- 必要に応じて新しい Juice Shop インスタンスを動的に作成
- 単一ドメイン上で動作し、LoadBalancer が参加者の Juice Shop インスタンスへトラフィックを振り分け
- 全参加者の進捗を表示する便利なリーダーボード
- インスタンス管理用の便利な管理ページ
- Juice Shop コンテナが再起動した場合に備えたチャレンジ進捗のバックアップと自動適用
- 古くて未使用のインスタンスを自動的にクリーンアップ
アーキテクチャと個々のコンポーネントの詳細については、アーキテクチャドキュメントを参照してください。
👉 MultiJuicer を初めて使う方へ: 参加者の登録方法、JuiceShop インスタンスの取得方法、スコアボードでのスコア追跡方法については、ビジュアルウォークスルーを参照してください。
インストール
MultiJuicer は kubernetes 上で動作します。インストールには helm が必要です
helm install multi-juicer oci://ghcr.io/juice-shop/multi-juicer/helm/multi-juicer
MultiJuicer を実際のイベントで使用する前に設定が必要になる可能性が高い値のチェックリストについては、本番環境の注意事項を参照してください。
JuiceShop v20+ の AI/LLM 関連チャレンジをサポートする MultiJuicer をセットアップするには、AI/LLM 設定ガイドを参照してください。
特定のクラウドプロバイダー / 環境向けのインストールガイド
一般的に MultiJuicer はほぼすべての Kubernetes クラスターで動作しますが、Kubernetes に不慣れな方でも簡単に始められるよう、特定のクラウドプロバイダー向けに MultiJuicer をインストールした Kubernetes クラスターのセットアップ方法を解説したガイドを用意しています。
セットアップのカスタマイズ
スタックのセットアップ方法にはいくつかのオプションがあり、JuiceShop インスタンスを好みに合わせてカスタマイズするオプションもあります。 デフォルトの設定値は次の場所で確認できます: helm/multi-juicer/values.yaml
ファイルをダウンロードして保存し、デフォルトの代わりにご自身の設定ファイルを使用するよう helm に指示するには、次を実行します:
helm install -f values.yaml multi-juicer ./multi-juicer/helm/multi-juicer/
JuiceShop インスタンスと MultiJuicer UI のテーマ設定(テーマ、ロゴ、有効なチャレンジなど)をカスタマイズするには、JuiceShop カスタマイズガイドを参照してください。
アンインストール
helm delete multi-juicer
FAQ
クラスターにはどの程度のコンピューティングリソースが必要ですか?
安全側に倒すなら、以下で計算してください:
- MultiJuicer 自体に 1GB メモリ & 1CPU のオーバーヘッド
- 個々の JuiceShop インスタンスに 384MB & 0.1CPU × 参加者/チーム数
上記の数値はデフォルトのリソース制限を反映しています。これらは調整可能です。詳細は セットアップのカスタマイズ を参照してください。
MultiJuicer は何人のユーザーを処理できますか?
実際の固定上限はありません。(設定することもできますが 😉) 個々のインスタンスへのすべてのトラフィックが流れるカスタム LoadBalancer は、好きなだけレプリケートできます。 また、Horizontal Pod Autoscaler をアタッチして LoadBalancer を自動スケールさせることもできます。
なぜカスタム LoadBalancer なのですか?
既製のロードバランサーでは簡単に解決できない、いくつかの特別な要件がありました:
- デプロイメントのユーザー数を特定のチームのメンバーだけに制限すること。
- ロードバランサーの Cookie は安全で、別のインスタンスにアクセスするために簡単に偽装できないこと。
- 新しいインスタンスの起動を処理すること。
カスタムロードバランサーなしでこれらの問題を克服する素晴らしいアイデアがあれば、ぜひご連絡ください。お聞きしたいです!
なぜチームごとに別々の Kubernetes デプロイメントなのですか?
これにはかなり良い理由があります:
- チームのインスタンスを個別に削除できること。アクティブなチームのインスタンスを削除せずに安全にスケールダウンすることは、スケールされたデプロイメントでは非常に困難です。保持する Pod と破棄する Pod を選択できず、希望するスケールしか選べません。
- Pod が再作成された後も、Pod がチームに適切に関連付けられていることを保証するため。これは別々のデプロイメントでは問題になりませんが、スケールされたデプロイメントでは非常に困難です。
- デプロイメント名にチーム名を埋め込めること。これは愚かな理由のように思えますが、
kubectlを使うだけでデバッグがはるかに簡単になります。
kubectl を使って JuiceShop を簡単に管理するには?
kubectl の custom-columns 機能を使って、関連情報とともにすべての JuiceShop を一覧表示できます。
$ kubectl get -l app.kubernetes.io/name=juice-shop -o custom-columns="TEAM:metadata.labels.team,SOLVED-CHALLENGES:metadata.annotations.multi-juicer\.owasp-juice\.shop/challengesSolved,LAST-REQUEST:metadata.annotations.multi-juicer\.owasp-juice\.shop/lastRequestReadable" deployments
TEAM SOLVED-CHALLENGES LAST-REQUEST
foobar 3 Wed May 4 2042 18:14:22 GMT+0000 (Coordinated Universal Time)
team-42 0 Wed May 4 2042 18:14:30 GMT+0000 (Coordinated Universal Time)
the-empire 0 Wed May 4 2042 18:14:46 GMT+0000 (Coordinated Universal Time)
このプロジェクトの由来
このプロジェクトは、ドイツに拠点を置くソフトウェア開発企業 iteratec で、自社の開発者やクライアント向けのセキュリティトレーニングを実施するために始まりました。 その後、2019年にオープンソース化され、2023年にOWASP組織/OWASP Juice Shopプロジェクトへ寄贈されました。
私たちと話しましょう!
OWASP Slack Workspaceの #project-juiceshop チャンネルで私たちに連絡できます。皆さんからのフィードバックや利用報告をぜひお聞かせください。まだOWASP Slack Workspaceに参加していない場合は、このリンクから参加できます。