vHoge

VMwareのアレコレ備忘録。CLIでがんばるネタ多め。

VMSA-2024 を数える

年も明けたので 2024年に発行された VMSA を数えてみただけのポスト。
何かの役に立つかも。

VMSA 一覧

VMSA ベースで22件、CVE ベースだと49件
ちなみに2023年の VMSA は27件なので減少っぽいが、Omnissa 分(2024年は2件)が分かれての件数なのでそこまでは変わっていないか。。。

VMSA Product Severity CVE count
VMSA-2024-0001 Aria Automation Critical 1
VMSA-2024-0002 Aria Operations for Networks Important 5
VMSA-2024-0003 Enhanced Authentication Plug-in Critical 2
VMSA-2024-0004 Aria Operations Moderate 1
VMSA-2024-0005 Workstation/Fusion Moderate 1
VMSA-2024-0006 ESXi/Workstation/Fusion Important/Critical/Critical 4
VMSA-2024-0007 Cloud Director Moderate 1
VMSA-2024-0008 SD-WAN Edge/SD-WAN Orchestrator Important 3
VMSA-2024-0009 Avi Load Balancer Important 2
VMSA-2024-0010 Workstation/Fusion Critical 4
VMSA-2024-0011 vCenter/ESXi/Workstation/Fusion Important 3
VMSA-2024-0012 vCenter Critical 3
VMSA-2024-0013 vCenter/vCenter Moderate 3
VMSA-2024-0014 Cloud Director Moderate 1
VMSA-2024-0015 Cloud Director Object Storage Extension Moderate 1
VMSA-2024-0016 Cloud Director Availability Moderate 1
VMSA-2024-0017 Aria Automation Important 1
VMSA-2024-0018 Fusion Important 1
VMSA-2024-0019 vCenter Critical 2
VMSA-2024-0020 NSX Moderate 3
VMSA-2024-0021 HCX Important 1
VMSA-2024-0022 Aria Operations Important 5

製品別件数

製品/深刻度別での集計。
1件の VMSA で複数製品を含んでいるものがあるので VMSA 件数とは合わないです。

Product Critical Important Moderate Low
ESXi 2 1
vCenter 2 1 1
NSX 1
Aria Operations 1 1
Aria Operations for Networks 1
Aria Automation 1 1
HCX 1
Cloud Director 2
Cloud Director Object Storage Extension 1
Cloud Director Availability 1
Avi Load Balancer 1
SD-WAN Edge/Orchestrator 1
Workstation 2 1 1
Fusion 2 2 1
Enhanced Authentication Plug-in 1
8 12 10 0

御覧の皆様、Critical なものぐらいは対応済ですよねぇ…?

思い出

印象に残っているものといえば VMSA-2024-0019
また vCenter の DECRPC 絡みで Critical か…とザワザワする中、8.0 U3b / 7.0 U3s へのアップグレードを案内していったおよそ1月後に完全な修正ではなかったとの判断により 8.0 U3d / 7.0 U3t のパッチ再リリース…
こんなパターンは初めて見た気がする。

機会があれば

この手の集計は数年レンジで見てみて傾向とか気づきがありそうな気がしていますので、時間があればもう少し過去のものも集計してみたいと思いますが、あまり昔の VMSA を掘り起こしてもなぁという気も。

vCenter で Okta を IdP として利用してみる(力業編)

前回からの続き。

vhoge.hateblo.jp

vSphere Client から Okta ログイン画面を経由し、Okta で認証できるようになったが、Okta で認証されたユーザー情報が vCenter 側にいないため vSphere Client 操作時にユーザーが不明でエラーとなる話で、Okta で登録されているユーザーを vCenter 側へプロビジョニングする必要があるが、SCIM エンドポイントのために Okta から vCenter へ HTTPS 到達性が必要なのであった…

Okta からの接続をトンネル+リバースプロキシする

Okta のユーザー情報を同期しておくのであれば vCenter への接続性を常時保っておく必要があるが、検証用としてユーザーの変更を行わないのであればひとまず初回同期だけできればなんとかなりそう…
ということで調べていると ngrok というサービスが。

ngrok.com

ngrok とは

ngrok とは API GatewaySaaS サービス。
面白いのはクライアントサイドで ngrok のエージェントを起動することで、クライアントから ngrok に対しトンネリングを行い、ngrok 側で発行された一時的な公開用 FQDN にアクセスすることでトンネル経由でクライアント上のアプリを公開することができる。 一歩間違えればセキュリティ事案…みたいなサービスですが…開発中の Web アプリを一時的に公開してテストするとかには需要がありそうなサービス。
独自ドメインやアドレス固定など行うのであれば有料となるが、ngrok が払い出す可変式の一時ドメインでの公開であれば無料で使用することができる。

ngrok の sign up

ngrok も Github or Google からアカウント作成が可能。 こちらも MFA 設定やアンケート(?)入力することでログインし、ダッシュボードが開く。

vCSA 内で ngrok エージェントを起動する

ngrok のダッシュボードより Linux の ngrok のエージェントの tgz をダウンロード。 vCSA 上で展開し、token の登録を行う

root@vcsa03 [ ~ ]# tar -xvzf ngrok-v3-stable-linux-amd64.tgz -C /usr/local/bin
root@vcsa03 [ ~ ]# ngrok config add-authtoken hogehoge-token
Authtoken saved to configuration file: /root/.config/ngrok/ngrok.yml

ngrok エージェントを起動する。この際、vCenter へのアクセスは vCenter FQDN での HTTP リクエストの Host ヘッダが必要なため、--host-header オプションにて vCenter の FQDN を指定する。
(vCenter 側で Apache で言うところの Virtual Host っぽい動きをしている)

root@vcsa03 [ ~ ]# ngrok http https://vcsa03.mirie.lab --host-header="vcsa03.mirie.lab"

起動すると ↓ のような画面が表示され、Forwarding の URL にアクセスすると vCenter へのプロキシとして転送してくれる。また、コンソール上には ngrok 経由でのアクセスログが出力される。 なお、Forwarding の URL は ngrok エージェント起動毎に変化する。

SCIM でのユーザープロビジョニング

ngrok 経由で公開している FQDN に対し Okta から SCIM でのユーザープロビジョニングを投げ込む。 Okta のアプリケーションより[アプリカタログを参照]を開き、”SCIM”で検索、"SCIM 2.0 Test App (OAuth Bearer Token)"を選択し統合を追加する。 アプリケーションラベルは適当な名前を設定、他はデフォルトで次へ。 サインインオプション画面にて、アプリケーションユーザー名の形式を適当なものを選び完了する。 登録した SCIM アプリを開き、割当タブからプロビジョニングするユーザー/グループを指定する。 プロビジョニングタブを開き、[API 統合を構成]を行う。 API 統合を有効化にチェックを入れると SCIM 2.0 Base Url / OAuth Bearer Token 入力欄が表示される。 SCIM 2.0 Base Url / OAuth Bearer Token は vSphere Client から持ってくる。
生成リンクよりシークレットトークンを生成し、コピペで OAuth Bearer Token へ入力。 SCIM 2.0 Base Url はテナント URL になるが、ここで vCenter の FQDN 部分は ngrok で払い出された公開用 FQDN に置き換えて貼り付ける。 [API 資格情報をテスト]を実行、問題なければ正常に検証されましたが表示される。 これで保存を押して完了。ユーザープロビジョニングが実行され、Okta 側で SCIM に割り当てを行ったユーザーやグループが vCenter 側に登録される。 最後にOkta で登録されたユーザーに対し vCenter で権限割り当てを行っておく。

Okta でログイン

これでようやく Okta からのログイン経由で vSphere Client を触ることができる。 認証が Okta 側に行ってしまったので、あとは Okta 側の設定次第で SNS なり Windows Hello/Touch ID なり Okta Verify なりをかけ多要素認証を適用することが可能なはず(あまり Okta 側は触ってないのでわからない)

まとめ

vCenter の IdP として Okta と連携してみました。
ドキュメント読む限り Entra ID も PingFederate も OpenID Connect + SCIM でのユーザープロビジョニングで Okta と似たようなものなのでで、(PingFederate はちょっとさておき) Okta /Entra ID なら使っているところも多いので、サービスアドオン感覚で vCenter の多要素認証や SSO を実現はできそうですが、ネックになりそうなのは SCIM のための外部 IdP から vCenter に対する接続性か…(+ vCenter FQDN の Host ヘッダ指定のためのリバースプロキシ)
ホームラボで試してみるぐらいであれば今回の ngrok でまぁなんとか。
このサービス、結構あぶなっかしいけど面白いですね…

vCenter で Okta を IdP として利用してみる(公式手順編)

こちらの投稿は vExperts Advent Calendar 2024 の 23 日目になります。
昨年が古のテクノロジーの話かと思えば今回は新しめの話と興味の赴くまま。。。 adventar.org そして、今回は長くなりすぎたので前後半に分かれています

vCenter での外部 IdP 利用

vCenter 8.0 U1 より Okta、8.0 U2 より Microsoft Entra ID、8.0 U3 より PingFederate と IDaaS を外部 IdP として利用できるようになりました。

docs.vmware.com

最近、セキュリティ的な話から多要素認証をやりたいというお話をチラホラ聞く機会がでてきました。vCenter での多要素認証というとその昔からスマートカードRSA SecurID があったのですが、わざわざ物理ソリューションを導入するのはなぁ…という状況において IDaaS の外部 IdP 対応が来たことで、多要素含めた認証周り(と SSO) は IDaaS におまかせして vCener のアカウント管理やセキュリティ強化をしてしまえそうということで、vCenter と IDaaS との連携がどんなものか検証してみる。

Okta Developer

実際にホームラボで検証してみようとなった場合、外部サービス利用となると利用料が発生しなかなか気軽にはいかないところ…ですが、Okta の場合は開発者向けにユーザー数や機能で制限つきではあるが無償で利用可能な Okta Developer が提供されているので、こちらを利用し検証してみる。

Home | Okta Developer

[Sign ip]からアカウント作成に進むと会社用メールアドレスが求められるが、[Log in] から進んでいくと Github アカウント or Google アカウントから Okta のアカウント作成ができる。

GithubGoogle での確認画面、Okta Verify(Okta の多要素認証アプリ)の登録を行うことでログインでき Okta 管理者のスタートページが表示される。

vCenter との連携設定を行う

前提条件や手順は以下の Doc.

Okta に対する vCenter Server ID プロバイダ フェデレーションの構成

細かい手順は以下の KB も参考に。

How to Enable Okta for vCenter Server

手順が動画でも公開されているので、画面操作とかはこちらが参考になる。

vCenter Authentication: Okta integration | vSphere 8

Okta 側のでアプリ作成

まず、Okta 側で連携するアプリの作成を行っておく。
メニューよりアプリケーションを開き、新しいアプリを作成。
作成アプリについてのモーダルが開くので、OIDC / ネイティブアプリケーションを選択。 適当なアプリ統合名を入力、付与タイプでは「リフレッシュトークン」と「リソース所有者のパスワード」についかでチェックを入れる。 画面下部、アクセス制御にて「今はグループの割り当てをスキップ」にて保存。
サインインリダイレクト URI も変更する必要があるが、それはのちほど。。。 作成したアプリの一般タブより、クライアントの資格情報にてクライアント認証を「クライアントシークレット」に入力、また PKCE 要求のチェックは外して保存。 新しいシークレットを生成する。

ユーザーの追加、割り当て

別に必須ではないが、検証用に Google アカウントで作成したユーザーとは別に Okta 内でユーザーを作成しておく。
(企業だとこの辺は Active Directory やどこかから連携したりとかかな…) さきほどの vCenter アプリより、割り当てタブより作成したユーザーを割り当てる。

vCenter 側の設定

vSphere Client にて [管理] → [Single Sign-On] → [設定] よりプロバイダの変更。 事前チェックを実行し、警告確認にチェックを入れて次へ。 ディレクトリ情報指定。ディレクトリ名はともかく、ドメイン名は Okta と合わせる必要があるのかな…? OpenID Connect 情報の入力、ここでデフォルトで表示されているリダイレクト URI はさきほどスキップしたサインインリダイレクト URI に指定する必要があるので、Okta 側に設定する。 vSphere Client 側に戻って空欄側を埋める。ID プロバイダ名は適当な名前、クライアント識別子/共有シークレットは Okta の作成したアプリの一般タブで出ている情報、OpenID アドレスは(調べたところによると) https://[okta テナント FQDN]/.well-known/openid-configuration らしい。 これで確認し、登録完了。 一応ここまで完了するとログイン画面が変化し、ログインが Okta 側に飛ばされるようになる。 一応これで認証は Okta に切り替わったが、認証後に vSphere Client に戻ってきた際、認証されたユーザーが vCenter 側にいないため vSphere Client が表示されることなくエラー画面に飛ばされてしまう。 そのため、Okta から vCenter に対しユーザープロビジョニングを行いユーザーを作成し、ロールを割り当てる必要がある…

が…

Okta からのユーザープロビジョニングは SCIM にて行われるが、そのためには Okta から vCenter に対し HTTPS での接続が必要
(ちなみに Okta ドメインのユーザーは vSphere Client から手動で作成はできないっぽい?)
改めて公式ドキュメントの要件を見ても… 会社でやるにおいても Okta から vCenter に対して HTTPS の到達性を確保するのは(セキュリティ的に)なかなか調整が大変気がしますが、我が家の場合ネットワーク環境的に外部公開は難しいので正攻法だとココで終了なワケですが、言うてもホームラボ、ここは力業で Okta からの到達性を確保しユーザープロビジョニングを行い、Okta ログインを完成させる。

vCenter で Okta を IdP として利用してみる(力業編) へ続く…!

vhoge.hateblo.jp

vCSA の SSH ログインに Google Authenticator を利用して二段階認証をかける

実験してみたシリーズ。 Advent Calendar のネタは出来てないのに大丈夫なのか…?
非サポートなので自己責任!本番環境では非推奨です!

SSH ログインに Google Authenticator

Google Authenticator(Google 認証システム)は、Googleが開発した二段階認証(二要素認証)を行うトークンソフトウェアである。Authenticatorは、Googleログイン時の二段階認証に必要な6桁の数字コードを生成する。また、LastPassDropboxといった他社製のアプリケーションの二段階認証にも対応する。

Google Authenticator - Wikipedia

ログイン時にアプリなどで時間で変化する 6桁のコードを生成し、入力することでログインできるようになるアレの Google 版ですが、Google の仕組みは PAM 経由で Linux サーバの認証で使える lib が OSS として開発、公開されていたりする。

github.com

Linux にいけるということは vCSA でも使えるんじゃないか…ということで試してみる。

環境

今回試した環境は(雑に立ててた) vCenter Server 8.0 U3c。
(U3d じゃないのかよというツッコミはノーサンキュー)
今回の記事では割愛するが、vCenter Server 7.0 U3t でも動いた。
(7.0 U3 だと gcc がデフォルトなかったので追加インストールする必要あり)

インストール

よくある Linux ディストリビューションであれば yum なり apt なりでインストールできるみたいだが、残念ながら vCSA(Photon) のリポジトリには入っていないのでソースからのコンパイル
幸いなことにコンパイルに必要なものはすべてtdnfで取得できる。

root@vcsa03 [ ~ ]# tdnf install autoconf automake binutils make linux-api-headers Linux-PAM-devel

Installing:
binutils-libs                        x86_64             2.35-14.ph4              photon-updates       4.09M 4292472
Linux-PAM-devel                      x86_64             1.5.3-3.ph4              photon-updates     196.28k 200988
linux-api-headers                    noarch             5.10.210-1.ph4           photon-updates       5.19M 5438242
make                                 x86_64             4.3-2.ph4                photon-release       1.35M 1418198
binutils                             x86_64             2.35-14.ph4              photon-updates      27.37M 28699422
automake                             noarch             1.16.1-3.ph4             photon-updates       1.37M 1436542
autoconf                             noarch             2.69-10.ph4              photon-updates       1.70M 1783277

Total installed size:  41.26M 43269141
Is this ok [y/N]: y
【略】

それと Github から Google-authenticator-libpam のソースをダウンロードし、解凍する。

root@vcsa03 [ ~ ]# wget https://github.com/google/google-authenticator-libpam/archive/refs/tags/1.10.tar.gz
--2024-12-08 22:44:57--  https://github.com/google/google-authenticator-libpam/archive/refs/tags/1.10.tar.gz
Resolving github.com... 20.27.177.113, 64:ff9b::141b:b171
【略】
2024-12-08 22:45:01 (636 KB/s) - ‘1.10.tar.gz’ saved [64409/64409]

root@vcsa03 [ ~ ]# tar -xvzf 1.10.tar.gz
google-authenticator-libpam-1.10/
google-authenticator-libpam-1.10/.github/
【略】
root@vcsa03 [ ~ ]# ls
1.10.tar.gz  google-authenticator-libpam-1.10

Github の手順の通りbootstrap.sh./configuremakemake install

root@vcsa03 [ ~ ]# cd google-authenticator-libpam-1.10/
root@vcsa03 [ ~/google-authenticator-libpam-1.10 ]# ./bootstrap.sh
libtoolize: putting auxiliary files in AC_CONFIG_AUX_DIR, 'build'.
libtoolize: copying file 'build/ltmain.sh'
【略】
Makefile.am: installing 'build/depcomp'
parallel-tests: installing 'build/test-driver'
root@vcsa03 [ ~/google-authenticator-libpam-1.10 ]# ./configure
checking whether make supports nested variables... yes
checking for gcc... gcc
【略】
config.status: executing libtool commands

  google-authenticator version 1.10
  Prefix.........: /usr/local
  Debug Build....:
  C Compiler.....: gcc -g -O2 -Wall
  Linker.........: /usr/bin/ld -m elf_x86_64  -ldl

root@vcsa03 [ ~/google-authenticator-libpam-1.10 ]# make
make  all-am
make[1]: Entering directory '/root/google-authenticator-libpam-1.10'
【略】
make[1]: Leaving directory '/root/google-authenticator-libpam-1.10'
root@vcsa03 [ ~/google-authenticator-libpam-1.10 ]# make install
make[1]: Entering directory '/root/google-authenticator-libpam-1.10'
 /usr/bin/mkdir -p '/usr/local/bin'
【略】
make[1]: Leaving directory '/root/google-authenticator-libpam-1.10'
root@vcsa03 [ ~/google-authenticator-libpam-1.10 ]#

make install/usr/local/lib/security にインストールされる

root@vcsa03 [ /usr/local/lib/security ]# ls
pam_google_authenticator.la  pam_google_authenticator.so

ここだとパスが通っていないので、/usr/lib64/security にリンクを作っておく。

root@vcsa03 [ ~ ]# ln -s /usr/local/lib/security/pam_google_authenticator.so /usr/lib64/security/pam_google_authenticator.so
root@vcsa03 [ ~ ]# ls -l /usr/lib64/security/pam_google_authenticator.so
lrwxrwxrwx 1 root root 51 Dec  8 23:14 /usr/lib64/security/pam_google_authenticator.so -> /usr/local/lib/security/pam_google_authenticator.so

sshd_config の設定

ChallengeResponseAuthentication yes を追記しておく。

root@vcsa03 [ ~ ]# echo "ChallengeResponseAuthentication yes" >> /etc/ssh/sshd_config

(無くてもいいんじゃないか、、、という気もしている)

/etc/pam.d/sshd の設定

設定ファイルに追記。

 # Begin /etc/pam.d/sshd

auth            required        pam_google_authenticator.so nullok echo_verification_code ★ この行(表示幅の関係で改行されているかも)
auth     [success=done new_authtok_reqd=done default=ignore perm_denied=die] pam_mgmt_cli.so /usr/lib/applmgmt/linux_cli/bin/getticket
account  sufficient     pam_mgmt_cli.so /usr/lib/applmgmt/linux_cli/bin/getticket
auth            include         system-auth
account         include         system-account
password        include         system-password
session         include         system-session

# End /etc/pam.d/sshd

追記する位置について、シェルが bash の場合は末で問題ないが、どうも appliancesh の場合だとauth [success=done ... 行より前にないとパスワード認証が通った段階で appliancesh が起動してしまう。
auth [success=done の内容を読み解いて直せばいいのだろうが、そこは妥協し先頭に書いておく。

google-authenticator の初期化

google-authenticator を初期化し、シークレットキーを生成する。

root@vcsa03 [ ~ ]# google-authenticator

Do you want authentication tokens to be time-based (y/n) y
Failed to use libqrencode to show QR code visually for scanning.
Consider typing the OTP secret into your app manually.
Your new secret key is: 【hogehoge】
Enter code from app (-1 to skip):

キーが生成されるので、これをアプリの Google Authenticator に登録する。

登録が問題なければアプリ側で6桁のコードが表示されるようになるので、それをEnter code from app に入力し先へ進める。

Enter code from app (-1 to skip): 111111
Code confirmed
Your emergency scratch codes are:
  【hogehoge】

Do you want me to update your "/root/.google_authenticator" file? (y/n) y

Do you want to disallow multiple uses of the same authentication
token? This restricts you to one login about every 30s, but it increases
your chances to notice or even prevent man-in-the-middle attacks (y/n) y

By default, a new token is generated every 30 seconds by the mobile app.
In order to compensate for possible time-skew between the client and the server,
we allow an extra token before and after the current time. This allows for a
time skew of up to 30 seconds between authentication server and client. If you
experience problems with poor time synchronization, you can increase the window
from its default size of 3 permitted codes (one previous code, the current
code, the next code) to 17 permitted codes (the 8 previous codes, the current
code, and the 8 next codes). This will permit for a time skew of up to 4 minutes
between client and server.
Do you want to do so? (y/n) y

If the computer that you are logging into isn't hardened against brute-force
login attempts, you can enable rate-limiting for the authentication module.
By default, this limits attackers to no more than 3 login attempts every 30s.
Do you want to enable rate-limiting? (y/n) y

緊急用の復旧コードが表示されるので控えておく。
その他、サーバサイド側でのキーの配置や各種設定が聞かれるが、ここはデフォルトにしておくのが無難かな。。。
最後にsshdを再起動

root@vcsa03 [ ~ ]# systemctl restart sshd

この後動作確認だが、このコンソールセッションはそのままで別ターミナルで新たに接続して確認するのが安全。

動作確認

別ターミナルよりsshで接続。

$ ssh [email protected]

VMware vCenter Server 8.0.3.00300

Type: vCenter Server with an embedded Platform Services Controller

([email protected]) Verification code: 222222 ★アプリの6桁の数字を入力
([email protected]) Password: ★ root ユーザのパスワード
Last login: Sun Dec  8 23:02:26 2024 from 192.168.1.13
Connected to service

    * List APIs: "help api list"
    * List Plugins: "help pi list"
    * Launch BASH: "shell"

Command>

/etc/pam.d/sshd の記述が先頭に来たことでアプリの6桁コードがまず聞かれるため若干違和感があるが、一応動作上は問題なく、コードもパスワードも正しいものを入力しないとログインできないため、一応目的は達成。 基本 SSH は Disable でも問題ないので、vCenter の機能的には問題ない…はず。
(vSphere Client でざっと見ではエラーなし)

終わりに

Google Authenticator を利用して SSH に対して二段階認証を試してみるお話しでした。
vCSA ができた = Photon OS ベースな他のアプライアンスに対しても適用できるものかと思いますが、あくまで非公式・非サポート、自己責任な内容となりますので、ラボ環境とかでならいいんじゃないですかね。。。

USB パススルーで仮想マシンに USB メモリを挿してみる

機能としては耳にするが実際に使っている人はあまり聞かない USB パススルーで、仮想マシンに USB メモリを挿してファイルをやりとりできるか試してみる。

試したデバイス

SanDisk SDDDC2-256G-G46 256GB
USB-Type-A/C のデュアルコネクタモデル
Amazon で見当たらなかったので kakaku.com より。
256GB、USB 3.0、Type-A/C デュアルコネクタで3000円とか良い時代や… kakaku.com
こちらに Windows 端末より exFAT でフォーマットをし、適当なファイルとして vCSA のインストーラ ISO イメージファイルをコピっておく。

ESXi に接続

公式ドキュメントは ↓ docs.vmware.com デフォルトでインストールされている USB アービトレータサービスが USB デバイスの接続を検出し、ESXi から USB デバイスへのトラフィックパスを構成する。

[root@hm90:~] /etc/init.d/usbarbitrator status
usbarbitrator is running
[root@hm90:~] ps | grep usbarbitrator
1049574  1049574  vmware-usbarbitrator

チェーン階層数や速度などもろもろ細かい要件や制約はあるが、実験的に USB メモリ1個接続するだけなので、細かいことは気にせずにひとまず装着!
ESXi のイベントを眺めていると USB 構成変更のイベントが出力される。
ESXi shell 上でlsusbを実行すると接続したデバイスが確認できる。

[root@hm90:~] lsusb
Bus 001 Device 001: ID 0e0f:8003 VMware, Inc. Root Hub
Bus 002 Device 001: ID 0e0f:8003 VMware, Inc. Root Hub
Bus 003 Device 001: ID 0e0f:8003 VMware, Inc. Root Hub
Bus 001 Device 002: ID 2109:3431 VIA Labs, Inc. Hub
Bus 003 Device 002: ID 0d8c:0014 C-Media Electronics, Inc. Audio Adapter (Unitek Y-247A)
Bus 003 Device 003: ID 0e8d:0608 MediaTek Inc.
Bus 001 Device 003: ID 0b95:1790 ASIX Electronics Corp. AX88179 Gigabit Ethernet
Bus 002 Device 002: ID 0781:5595 SanDisk Corp. ★コレ

仮想マシンに接続する

仮想マシンに USB を接続する場合、仮想マシンのデバイスに仮想 USB コントローラを作成しておく必要がある。 docs.vmware.com 仮想マシン作成時に Windows 系の OS を選択している場合はデフォルトで仮想 USB コントローラが作成される。
Linux 系など、Windows 以外の OS の場合はデフォルトでは作成されないので個別に作る必要がある。
接続した USB メモリを接続するには新規デバイスを追加よりホストの USB デバイス
新規ホスト USB デバイスが追加されるので、追加する USB デバイスを選択し OK。
仮想マシンのハードウェア情報に追加した USB デバイスが表示される。
これで vSphere Client 側の作業は終わり。

仮想マシンの中から見てみる

仮想マシン内の OS(Windows Server 2016)から見ると E ドライブが追加されている。
中も見えて、さきほどコピった vCSA の ISO ファイルが。
ローカルにコピー。ほぼ Max 速度?
ISO もマウントでき、インストーラも起動。問題なし。

USB デバイスを取り外す

まずは仮想マシン内から。Windows OS で普通に取り外し。
(最近の Windows だとコレで外さなくてもいいらしい?)

OS でアンマウントできたら仮想マシンより取り外し。
仮想マシンの編集からデバイスの削除。

問題なくデバイス削除できたら物理的に取り外しておk。

USB メモリを挿した状態で vMotion しようとする。

当然ながら移動先ホストにデバイスが無いので怒られる。
USB デバイスが接続された状態でも vMotion 自体はサポートされているので移動先ホストにも同じ USB デバイスがあれば vMotion できるはずだが、ストレージ系の USB デバイスはどうなんだろう…

余談

自宅でなら数 GB ぐらいのサイズのファイルを仮想マシン内にもっていくぐらいのユースケースがあるからなーと思ったが
USB メモリへの書き込みが遅杉…
USB HDD/SSD とならまだ速度でるかもだが、ネットワーク転送で十分なような…
使い道がやはり難しい。