NVIDIAがOpenShellの新バージョンを公開し、セキュリティログの形式と仮想マシンサンドボックスの実行アカウントの動作を変更した。ログの収集・分析やサンドボックスイメージの作成を担当する開発者は、新しいログ仕様とイメージで指定されたアカウントに合わせて連携・権限設定を点検する必要がある。
1. セキュリティログの受信形式が一つに変わる
2026年11月3日に公開されたv0.1.7は、セキュリティイベントを、イベント分類の標準であるOCSFの1.8.0形式でのみ出力する。これはイベントを決められた項目と構造で表すスキーマだ。旧仕様を選択していた環境も、更新すると新形式のレコード、すなわち項目別に整理されたイベントデータを受け取る。
従来1.1または1.3のレコードを受信していたデプロイ環境が移行対象となる。リリースノートはこれを互換性を損なう変更に分類した。ログを読み取るパーサー、つまりログ内容を解釈するプログラムや、脅威の兆候を探す条件である検知ルールが旧形式のフィールドと構造を前提としているなら、新レコードへの適合確認が先決だ。
旧仕様を選ぶ設定は廃止に向けた段階に入り、値を指定しても無視され、警告が記録される。システム間の通信を中継する構成要素であるゲートウェイの設定だけでなく、インストール設定をまとめたデプロイチャートや環境変数でバージョンを選択する経路も同じ扱いとなる。
検証基準も新形式に合わせた。リリースノートによると、サンドボックスを管理するスーパーバイザー、つまり仮想マシンの実行を管理する制御プログラムと、ゲートウェイのイベントは公式OCSF 1.8.0スキーマの検証に合格する。同ノートは、テストがOCSFスキーマサーバーの出力するJSON Schema、すなわちJSON構造の妥当性を検査する規則を基準にイベント構造を検査すると説明している。
2. イメージで指定したアカウントが実際の実行に反映される
軽量な仮想マシンを利用するMicroVM、つまりリソースを抑えた軽量仮想マシンのドライバーでは、レジストリのイメージやルートファイルシステムを収めたtarファイルから作成したサンドボックスが、イメージ内のsandboxアカウントで実行される。従来はユーザーとグループの識別番号が1000:1000に固定されていた。
新しい動作は、イメージに文書化された実行アカウントに従うようにした修正だ。イメージのsandboxアカウントがユーザー識別番号であるUID 1000を使わない場合、そのイメージから作成した新しいサンドボックスは、そのアカウントのUIDで実行される。
イメージ自体のUIDをrun_as_userとして要求する動作もサポートされる。イメージ作成者にとっては、アカウントの選択と実際の実行を一致させる変更だ。ファイルの所有権やアクセス権限を固定の番号に合わせた環境は、イメージの実行アカウントを基準に点検できる。
3. 制限の厳しい権限設定でも仮想マシンが起動する
仮想マシンサンドボックスの起動問題も修正された。ゲートウェイが、新規ファイルの既定のアクセス権限を制限するumaskを厳しく設定していても、仮想マシンサンドボックスを起動できるようになった。リリースノートは、パッケージに含まれるUMask=0077をその例に挙げた。
この修正はゲートウェイのファイル作成権限設定に関わる。イメージのアカウントに従う変更がサンドボックス内で誰が実行するかを正すのに対し、今回の修正は制限の厳しいゲートウェイ実行環境でサンドボックスを起動できるようにすることに重点を置く。
4. インストールと併せてログ連携・イメージの権限を確認する
リリースノートは次のインストールコマンドを提供している。インストールスクリプトに対象バージョンを指定する、原文の1行の例だ。
curl -LsSf https://raw.githubusercontent.com/NVIDIA/OpenShell/main/install.sh | OPENSHELL_VERSION=v0.1.7 shログ形式統一の利点は、収集・検証の基準を一つの仕様で管理できることにある。イメージのアカウントの反映は、作成段階のユーザー設定を実行段階と一致させる。その代わり、旧仕様に依存したログ連携と固定のアカウント番号を前提とする権限設定には移行作業が必要となる。
今回の更新の適用基準は、インストールの成功にとどまらず、新しいログを正しく読み取り、イメージで指定したアカウントでサンドボックスを実行できるかどうかにある。