暗号化されたvSAN環境でのKMS障害の影響
本記事では、vSAN 6.6以降登場した”キー管理サーバ(以下KMS)”を用いた暗号化vSANの機能にて、KMS自体に障害が起きた場合にどのような影響があるかを”VMware HOL”上でシミュレートした結果を掲示します。
具体的には次のような情報を掲示します。
- 暗号化されたvSAN概要
- KMSについて
- VMware HOL上でのKMSの障害再現方法
- vSAN暗号化環境において注意すべき事
では早速本編に移ります。
暗号化されたvSAN概要
本機能は、vSANデータストアに保存されているあらゆるデータを暗号化します。
これは、vSANに参加をしているディスクグループに暗号化対応のドライブフォーマットを適用する事で暗号化を提供します。暗号化済みのドライブは、暗号化されたホスト以外に接続をしても中のデータを読み取ることが出来ません。
記憶媒体に対する暗号化機能は、”自己暗号化ドライブ(Self Encryption Drive, SED)”もありますが、本機能を利用する際は、そうした特別なドライブは不要です。SED非対応のドライブでも暗号化が出来る秘密としては、”キー管理サーバ(KMS)”という役割のサーバにあります。
概要情報は公式に優れたものが多く存在するのでそちらを参照ください。
vSAN Encryption – Dell Technologies Infohub
KMSについて
KMSは、サードパーティのベンダーが提供しているものであり、VMwareのソリューションでは次の機能と利用可能です。
これらの機能は、いずれもKMSを利用します。特に暗号化については二つともアーキテクチャ自体も大変似ていますが、異なる機能ですのでご注意ください。vSAN暗号化の仕組み – VMware Docs
また、本機能で利用可能なサードパーティベンダーKMSはVMware Compatibility Guideで検索可能です。
VMware Compatibility Guide – KMS
さて、このKMSは仮想マシンベースで構成して展開するのですが、この仮想マシンを構成する際に守らないといけないルールがあります。それは、”KMSアプライアンス自体を、本KMSを使用して暗号化するデータストア上に配置してはならない”という事です。
この事については、次のページに記載されています。
保存データの暗号化を設計する際の考慮事項 – VMware Docs
VMware HOL上でのKMSの障害再現方法
本検証では、”KMSの接続性/応答性無し”の症状を再現します。
具体的には次のようなケースです。
- KMS仮想マシン起動不可
- KMS仮想マシンのハング
- KMS仮想マシンのネットワーク通信不可
基本的にKMSはvCenter ServerとESXiホストと通信できる必要があります。(暗号化/復号化のための鍵を入手/生成のため)検証で用いるVMware Hands on Lab環境では、Hytrust社のKeyControlが使用されています。
現象再現の紹介内でも画像が出てきますが、Webブラウザベースの管理画面を有している製品です。
本検証は次のVMware Hands on Lab環境上で実施しています。
HOL-2008-01-HCI -vSAN – Getting Started
(図内上部のコメントによると 6.7ベースのラボは2020/10/29にリタイアするそうです)
上記日程以降同様の検証が出来るであろうラボは次の通りです。
HOL-2108-01-HCI – What’s New in vSAN – Getting Started
Step1. vSAN 暗号化を有効にする
HOL開始時点で、既にKMSは展開済みです。かつHOL内のデスクトップにあるラボ構成スクリプトを使用して、既に暗号化シナリオを開始済みです。(KMSも自動で構成済み)
vSAN 暗号化はデフォルトでは無効です。ユーザーが有効化設定することで機能が動作し始めます。
なお本機能はクラスターレベルの機能です。有効化にするために、クラスターの”構成”タブから行います。
下図では暗号化は無効化状態であることが分かります。”Edit”から有効化メニューを起動します。
下図の”Encryiption”のスイッチを有効化します。なお新規で構成するクラスターでも、既存のクラスターでも有効化/無効化は出来ます。が、可能なら実運用開始前に有効化/無効化は決める方が良いです。
どうして、運用が始まったvSANでの暗号化機能の変更(有効から無効、無効から有効)をなるべくやるべきでないかというと、下図に示すようにディスクグループの再フォーマットが発生するためです。この操作により機能設定変更作業中の間はディスクグループの削除、再フォーマットが発生し、冗長性の低下やデータ移行が発生します。
これで正常に暗号化されたvSANクラスターになりました。
Step 2. KMS障害をシミュレートする
本来ならば、KMSをシャットダウンしたり、再起動するのが望ましいです。しかしHOL環境では権限や画面操作の制限があるためそれは出来ませんでした。
という事で、”KMS側の通信ポートを変更”する事で疑似的にKMS利用不可の状況を発生させます。
こちらが正しい設定(Port 5696)
正しくない設定に変更します(Port 5697)
これで準備は整いました。さて、ではvSAN環境をモニターしてみます。
KMSポート番号だけ変更した場合
これだけでは仮想マシンは停止しません。
本来KMSはどのタイミングで必要かというと、ESXiホストにとってはvmkernelの起動時です。
vmkernelが起動する際に、vCenter Serverに通信して”KMSに鍵を貰う際のKID”を得ます。
その後、ESXiがKMSに”〇番の鍵をください”と、まるでホテルのフロントで鍵を貰うように問い合わせをします。
ポート番号を変えただけでは、ESXiホストは元々取得済みの鍵を持っていますので影響がないありません。(これは予想通り)
しかしながら予想外だったのは、仮想マシンの新規作成の際の”データストア選択画面”ではストレージ領域を常に探し続ける動作になった点です。
Storage vMotionの画面ではデータストア一覧は表示されます。
データストアブラウザへのアクセス、中のデータのダウンロード、新規フォルダ作成は出来ました。
各画面上での振る舞いに一貫性があるようなないような。
KMSポート番号変更後、ESXiホストを再起動した場合
さて、これはまずいケースです。
まず確実に言えるのは”ESXiホストが再起動された後は、vSANディスクグループのマウントに失敗するであろう”、ということです。
案の定ですが、ディスクグループはアンマウント状態です。
各ホストに対しても暗号化関連のアラートも発生しています。
個別のドライブのステータスも未マウント状態で表示されています。
vSAN 健全性画面では、KMSとの接続性について警告が出ています。当然と言えば当然です。
意外なのは、vSAN Datastoreとしては正常なステータスが表示されていることです。但し容量は0GBです。
試しにフォルダ作成が出来るかを行いましたが、やはりNGです。
Step 3. KMS障害を回復させる。
今回のシナリオでは、単純にKMSの通信ポート番号を変えただけですので、次の方法で回復可能です。
- KMS通信用ポート番号を修正する
- 各vSAN ESXiホストを再起動しなおす
これだけでvSAN ディスクグループのマウントは正常に行われます。
なお、上記の作業前に、試しにドライブのスキャンを行いましたがこれは復活しませんでした。(KMSの接続性問題が継続して起きているため)
KMSのポート設定を正しい値に変更します。KMSとの接続性が復活しました。
上記確認の上全ホストの再起動を実施します。
この後、無事にvSAN ディスクグループのマウントが行われました。
vSAN暗号化環境において注意すべき事
ここまでの話を通して間違いなく言える事は、”ホストの停止を行う前には、KMSとvCenter Server及びESXiホストの接続性が正しいことを確認すること”です。以下の画面で確認が出来ますね。
もし万が一上記接続性が失われた状態でホストを再起動してしまっても、KMSとの接続性を回復後はディスクグループのマウントは行われます。
なお、最もNGな環境構成は”KMSそのものをvSAN暗号化データストアに保存すること”です。
KMS自体も仮想マシンとして提供されています。それをvSAN暗号化が機能するデータストアに保存する。
イメージとしては、オートロックドアのための鍵を、そのドア内の部屋に置くイメージです。
ホテルの場合は、フロントに言えばマスターキーもありますが、vSANの場合はそういうわけにはいきません。KMSをホストするサーバが再起動や不正なシャットダウンで落ちてしまうと、そのホストはその後ディスクグループがマウントできないでしょう。そういうリスクがあるため、VMwareでは、KMS仮想マシンを自身が暗号化保護しているデータストア上に配置しないように、と注意喚起しているわけです。
コメント