本文へ移動
Broadcom Watch Japan Broadcom Inc.（AVGO）の製品、サービス、ソリ...
製品・サービス・ソリューション 更新: 2026.06.05

VCF PowerCLI 9.1のOAuth 2.0認証：APIトークンとSSO連携を導入前に確認する

VCF PowerCLI 9.1でAPIトークンをIdentity Brokerに渡し、vCenter Server、NSX、VCF Operationsへ接続する流れを示す抽象サムネイル

追記: 2026年6月6日の最新情報

2026年6月5日に公開されたVCF 5.2.xから9.1への公式アップグレードガイドでは、AriaコンポーネントをVCF Operationsへ移し、License Server、Software Depot、Salt RaaSなどをVCF Management Servicesに集約する流れが示されました。PowerCLI OAuth 2.0を導入する場合は、APIトークンを作る前に、接続先のVCF Operations、Identity Broker、Management Servicesがアップグレード後のどの状態にあるかを確認してください。

  • 今回の公式ガイドで、`New-VcfOAuthSecurityContext`や`Connect-VIServer`の使い方が変わったとは確認していません。
  • ただし、VCF 5.2.xから9.1へ移る環境では、古いAria/ID管理の前提でトークン運用を決めないことが重要です。
  • 接続テストの前に、Identity Brokerのホスト名、Tenant、認証ドメイン、トークン保管、失効手順を運用メモに残してください。

公式アップグレードガイドはVMware Cloud Foundation 5.2.x to 9.1 Upgrade Guideです。PowerCLIの認証方式だけを先に決めず、アップグレード計画、管理サービス、証明書、監査ログを同じタイミングで確認すると、後戻りを減らせます。

このテーマをもう少し広げて見るなら、VCF 9.1のAPI-first自動化を導入前に確認する：Real-Time Metrics、vCenter Utilization、SDK/PowerCLIの実務ポイント と VCF Operations 9.1 Diagnosticsを旧vSphere/NSX環境で使う前に：Findings、ログ連携、更新方式を確認する も合わせて確認してください。PowerCLI OAuth認証を、VCF 9.1のAPI-first自動化全体の中に位置づけられる。

3行まとめ

VisualVCF PowerCLI 9.1 OAuth認証の要点APIトークンを使う前に、接続方式と運用前提を分けて確認します。
APIトークンでOAuth 2.0認証へ

VCF SSOのAPIトークンを使い、vCenter Server、NSX Manager、VCF Operationsへの接続を検討します。

直接利用か認証コンテキストか

`VcfApiToken`で足りる検証なのか、`New-VcfOAuthSecurityContext`で横断接続する運用なのかを切り分けます。

接続前に運用条件を決める

Identity Broker、Tenant、認証ドメイン、証明書、トークン保管、ログ方針を接続テスト前に確認します。

パスワードレス化は接続方式だけでなく、秘密情報の保管と失効まで含めて設計します。

  • VCF PowerCLI 9.1では、VCF SSOのAPIトークンを使ったOAuth 2.0認証が、vCenter Server、NSX Manager、VCF Operationsをまたぐ自動化の現実的な選択肢になりました。
  • まず確認すべきなのは、VcfApiTokenを直接渡す単純な接続で足りるのか、New-VcfOAuthSecurityContextで作った認証コンテキストを複数コンポーネントで使うべきかです。
  • 本番運用では、Identity Brokerのホスト名、Tenant、認証ドメイン、トークン保管、証明書、ログに残す情報を、接続テストの前に決めておく必要があります。

2026年6月1日、VMware Cloud Foundation Blogは「OAuth 2.0 Authentication Using VMware Cloud Foundation PowerCLI 9.1」を公開しました。この記事は、VCF 9.1の新機能を紹介するだけでなく、パスワードをスクリプトへ埋め込まないPowerCLI運用へ移るための実務的な入口になります。

Broadcom Watch Japanでは、株価材料よりも、利用者が触れる製品、サービス、運用変更を優先して追っています。今回の主役は、VCF PowerCLI 9.1の認証方式です。VCF 9.1全体の導入前チェックは、すでに公開済みの<a href="https://avgo-watch.blog.mo-gmo.com/avgo-13-vcf-91-upgrade-api-ip-check/">VCF 9.1導入前チェック記事</a>も合わせて確認してください。

VCF PowerCLI 9.1で変わった認証の位置づけ

VisualAPIトークンから各コンポーネント接続までVCF PowerCLI 9.1では、トークン発行と接続先ごとの認証を分けて考えます。
  1. 1VCF OperationsでAPIトークン発行

    パスワードをスクリプトに埋め込まず、APIトークンを認証の入口にします。

  2. 2VCF Identity Brokerで認証文脈を作る

    APIトークンをもとに、接続cmdletへ渡す認証コンテキストを準備します。

  3. 3vCenter Serverを確認する

    `Connect-VIServer`を基準に、認証ドメインや権限が合っているかを確認します。

  4. 4NSX ManagerとVCF Operationsへ広げる

    横断処理では、同じ認証文脈で複数コンポーネントへ接続できるかを確認します。

SDDC Manager、SDK、Terraform Providerまで広げず、PowerCLIでVCFコンポーネントへ安全に接続する範囲に絞ります。

PowerCLIの自動化では、昔から「人がCLIで入力する認証」と「ジョブが夜間に実行する認証」を分けて考える必要がありました。手元で一度だけ接続するなら、ユーザー名とパスワードを入力しても大きな問題にならない場面はあります。しかし、定期実行、CI/CD、構成棚卸し、監査ログ取得のような処理では、認証情報がファイル、環境変数、ログ、ジョブ定義に残るリスクが大きくなります。

VCF PowerCLI 9.1のOAuth 2.0認証は、この問題に対するBroadcomの公式な方向性を示しています。2026年6月1日の公式ブログは、VCF OperationsでAPIトークンを発行し、そのトークンを使ってVCF Identity Brokerで短命のBearer access token相当の認証コンテキストを作り、vCenter Server、NSX Manager、VCF Operationsへ接続する流れを説明しています。

この記事で扱う接続先

この記事では、公式ブログとVCF 9.1のPowerCLI関連情報で確認できる範囲に絞り、主に次の接続先を扱います。

接続先PowerCLIで見る主な入口この記事での扱い
vCenter ServerConnect-VIServerVcfApiToken直接利用とVcfOAuthSecurityContextの両方を比較する基準点
NSX ManagerConnect-NsxServer公式ブログが示すOAuth security context利用の横展開先
VCF OperationsConnect-VcfOpsServerVCF 9.1のプログラマブル基盤文脈で確認する横展開先

SDDC Manager、Terraform Provider、Python SDK、Java SDKまで広げると、記事の検索意図がぼやけます。今回は「PowerCLIでVCFコンポーネントへ安全に接続する」ことに絞ります。

OAuth 2.0認証で増えた選択肢

導入担当者が最初に迷うのは、APIトークンをそのまま接続cmdletへ渡すのか、New-VcfOAuthSecurityContextで認証コンテキストを作ってから各接続cmdletへ渡すのかです。

Broadcom DeveloperのConnect-VIServerリファレンスでは、VcfApiTokenとVcfOAuthSecurityContextのパラメータが確認できます。VcfApiTokenはVCF SSO APIトークンを使ってvCenterへ認証するためのパラメータで、そのトークンは対象vCenterが使う認証ドメインに対応している必要があります。VcfOAuthSecurityContextは、VCF SSOの認証コンテキストを渡すためのパラメータです。

一方、New-VcfOAuthSecurityContextのリファレンスでは、必須パラメータとしてApiTokenとIdentityBrokerHostnameが示されています。任意でTenantも指定できます。つまり、単に「トークンを持っている」だけでは十分ではありません。どのIdentity Brokerでトークン交換するのか、必要ならどのTenantを使うのか、対象コンポーネントがどの認証ドメインで受け付けるのかを合わせて確認する必要があります。

用語を混ぜない

APIトークン、Bearer access token、OAuth security context、VCF SSO、Identity Brokerは、記事や運用メモで混ざりやすい言葉です。

APIトークンは、公式ブログではVCF Operations UIから生成する長めの資格情報として説明されています。Bearer access tokenは、APIトークンをIdentity Brokerへ渡した後に得られる短命のアクセストークンです。VcfOAuthSecurityContextは、PowerCLIのcmdletへ渡すための認証コンテキストです。これらをすべて「トークン」とだけ呼ぶと、期限切れ、失効、保管、権限確認の切り分けが難しくなります。

APIトークン直接利用とVcfOAuthSecurityContextの違い

Visual接続方式の使いどころ単体検証と横断運用では、確認する前提が変わります。
項目内容見方
`VcfApiToken`直接利用vCenter Server単体の接続確認、短い棚卸し、手元での検証に向いた入口です。
`VcfOAuthSecurityContext`利用vCenter、NSX、VCF Operationsをまたぐ処理や、CI/CD、定期ジョブで扱いやすい方式です。
直接利用で見ること対象cmdletが`VcfApiToken`を受けるか、APIトークンと接続先の認証ドメインが合うかを確認します。
認証コンテキストで見ることIdentity Broker hostname、Tenant、証明書、時刻同期、各コンポーネントへの接続を分けて確認します。

直接利用と認証コンテキストは単純な優劣ではなく、検証範囲と運用範囲で選び分けます。

vCenter Server単体の短い確認なら、VcfApiToken直接利用から始めるのは自然です。複数コンポーネントへ接続するジョブ、共通関数化したいスクリプト、CI/CDで繰り返し動かす処理では、VcfOAuthSecurityContextを中心に設計した方が切り分けやすくなります。

ただし、これは「直接利用は雑で、OAuth security contextは安全」という単純な話ではありません。どちらの方式でも、APIトークンの発行元、権限範囲、保管場所、失効手順は重要です。

判断軸VcfApiToken直接利用VcfOAuthSecurityContext利用
代表的な使いどころvCenter Server単体の接続確認、短い棚卸し、手元での検証vCenter、NSX、VCF Operationsをまたぐ処理、CI/CD、定期ジョブ
事前に必要な情報APIトークン、対象サーバー、認証ドメインAPIトークン、Identity Broker hostname、必要に応じてTenant、対象サーバー
切り分け接続先とトークンの整合性を直接確認するトークン交換と各コンポーネント接続を分けて確認する
再利用性接続cmdletごとに扱いを確認する生成した認証コンテキストを複数接続へ渡す設計にしやすい
注意点対象cmdletがVcfApiTokenを受けるか実環境で確認するIdentity Broker、Tenant、証明書、時刻同期の影響を受ける

VcfApiTokenを直接渡す場合

VcfApiToken直接利用は、接続できるかどうかを最短で確認したいときに使いやすい方式です。たとえば、vCenter ServerへPowerCLIで接続し、インベントリ取得や簡単な構成確認を行う場合、最初の検証としては分かりやすい入口になります。

ただし、直接利用でも「APIトークンをどこに置くか」という問題は消えません。PowerShell履歴、CI/CDのジョブログ、エラー出力、スクリーンショット、チャット共有にトークンが残ると、パスワードを平文で残すのと同じ種類のリスクが生まれます。

接続確認用の短い例は、次の程度に留めるのがよいでしょう。実トークンや実ホスト名は、記事、手順書、チケットに残さないでください。

$apiToken = Read-Host "VCF API token" -AsSecureString
Connect-VIServer -Server "vc.example.local" -VcfApiToken $apiToken

確認する条件

Broadcom DeveloperのConnect-VIServerリファレンスでは、VcfApiTokenはVCF SSO APIトークンであり、対象vCenterが使う認証ドメインに対応している必要があると説明されています。したがって、接続前の確認は「PowerCLIのバージョンが新しいか」だけでは足りません。

確認する順番は、次のように分けると実務で迷いにくくなります。

確認項目見る内容失敗時に起きやすい症状
PowerCLIVCF PowerCLI 9.1相当のcmdlet構文があるかVcfApiTokenやVcfOAuthSecurityContextが見つからない
認証ドメインAPIトークンと対象vCenterの認証ドメインが合っているかトークンは正しく見えるのに認証に失敗する
権限APIトークンのスコープやロールが作業内容に足りるか接続後に取得や変更操作で拒否される
証明書PowerCLI実行環境から信頼できる証明書か接続時に証明書エラーが出る
保管トークンをどこに置き、誰が読めるかログ、履歴、ジョブ定義に秘密情報が残る

VcfOAuthSecurityContextを使う場合

VcfOAuthSecurityContextを使う方式では、APIトークンをNew-VcfOAuthSecurityContextへ渡し、VCF Identity Brokerでトークン交換を行い、得られた認証コンテキストを接続cmdletへ渡します。

$apiToken = Read-Host "VCF API token" -AsSecureString
$oauthContext = New-VcfOAuthSecurityContext `
  -IdentityBrokerHostname "vidb.example.local" `
  -ApiToken $apiToken

Connect-VIServer -Server "vc.example.local" -VcfOAuthSecurityContext $oauthContext

この方式の利点は、認証の前処理と各コンポーネントへの接続を分けて考えられることです。vCenter Serverだけでなく、NSX ManagerやVCF Operationsへ広げるジョブでは、最初に認証コンテキストを作り、その後の接続先ごとに失敗箇所を分けられます。

公式ブログでは、同じBearer access tokenをVCF Automation、VCF Operations、vSphere、VCF NSXなどのコンポーネントで利用できる流れが示されています。また、Bearer access tokenは短命で、公式ブログでは通常約30分で失効する旨が説明されています。記事では固定の保証値として扱わず、自分の環境の設定と公式ドキュメントで確認する前提にしてください。

Identity BrokerとTenantを先に確認する

New-VcfOAuthSecurityContextの必須パラメータは、ApiTokenとIdentityBrokerHostnameです。任意でTenantも指定できます。ここでつまずく環境では、PowerCLIの問題ではなく、Identity BrokerのFQDN、Tenant名、名前解決、証明書、時刻同期が原因になっていることがあります。

次のように、接続前に構文だけでも確認しておくと、古いPowerCLIや想定外のモジュールを使っていることに早く気づけます。

Get-Command New-VcfOAuthSecurityContext -Syntax
Get-Command Connect-VIServer -Syntax
Get-Command Connect-NsxServer -Syntax
Get-Command Connect-VcfOpsServer -Syntax

この確認は、実トークンを使わずに実行できます。CI/CDへ載せる前の作業端末、ジョブ実行ランナー、踏み台端末で、同じ結果になるかを見る価値があります。

導入前に確認する5つの項目

Visual本番運用前の5点チェック接続できるかだけでなく、運用に載せられる状態かを確認します。
VCF SSOと認証ドメイン

APIトークン、vCenter Server、NSX Manager、VCF Operationsが同じ認証文脈で扱えるかを確認します。

APIトークンの発行、保管、失効

発行者、権限、保管場所、ローテーション、担当変更時の失効手順を決めます。

Identity Broker hostnameとTenant

認証コンテキスト生成に必要なホスト名と、必要に応じたTenant指定を事前に整理します。

PowerCLI 9.1の導入状況

実行端末やジョブ環境で、VCF PowerCLI 9.1相当のcmdletとパラメータが使えるかを確認します。

接続後に何をするか

棚卸し、監視、設定変更、レポート、容量計画など、認証後の作業目的を明確にします。

導入前チェックを省くと、接続はできても秘密情報管理や権限運用で止まる可能性があります。

OAuth 2.0認証は、パスワードをスクリプトに置かないための有力な手段です。しかし、導入前の確認を省くと、接続はできても運用に載せられない状態になります。

ここでは、本番へ持ち込む前に確認したい項目を5つに分けます。

1. VCF SSOと認証ドメイン

最初に確認するのは、対象コンポーネントがVCF SSOの認証ドメインとどう結びついているかです。

Connect-VIServerのリファレンスでは、VcfApiTokenとVcfOAuthSecurityContextのどちらも、対象vCenterが使う認証ドメインとの整合性が重要になります。これは、単に「SSOが有効です」と言うだけでは足りません。どの認証ドメインのトークンなのか、対象vCenter、NSX Manager、VCF Operationsがその認証ドメインを受け付けるのかを確認します。

確認の聞き方

運用チームやID管理チームへ聞くときは、次のように具体化すると話が早くなります。

  • このAPIトークンは、どのVCF SSO認証ドメインで発行されるか。
  • 対象vCenter Serverは、その認証ドメインで認証できるか。
  • NSX ManagerとVCF Operationsにも同じ認証文脈で接続する想定か。
  • Tenant指定が必要な構成か。
  • 失効やローテーションは誰が実行するか。

2. APIトークンの発行、保管、失効

公式ブログでは、VCF Operations UIからAPIトークンを生成する流れが示されています。記事を書く側としては、画面操作を細かく再掲するより、発行後の扱いを強調した方が読者の事故を減らせます。

APIトークンは長めに使える資格情報として扱われるため、保存場所が重要です。手元のメモ、PowerShell履歴、平文の設定ファイル、チケット、チャット、ビルドログへ残してはいけません。ジョブで使う場合は、組織が使っているSecret Manager、CI/CDの保護された変数、権限を絞ったランナーなどに寄せるべきです。

項目確認する内容
発行者管理者が発行するのか、開発者が自己発行できるのか
権限トークンが持つロールやスコープが作業に過不足ないか
保管誰が読める場所に置くのか、ログへ出ないか
ローテーション期限切れ前に交換できる手順があるか
失効担当変更、端末紛失、権限変更時にすぐ無効化できるか

3. Identity Broker hostnameとTenant

VcfOAuthSecurityContextを使う場合、Identity Broker hostnameは必須です。Tenantは任意パラメータですが、環境によっては指定が必要になる可能性があります。

ここを曖昧にしたままPowerCLIの接続テストを始めると、エラーの原因が見えにくくなります。APIトークンが間違っているのか、Identity Brokerへ到達できないのか、Tenantが違うのか、証明書が信頼されていないのかが混ざるためです。

切り分けの順番

本番ジョブに入れる前に、次の順番で確認します。

  1. PowerCLI実行環境からIdentity BrokerのFQDNを名前解決できる。
  2. HTTPS接続時の証明書チェーンを信頼できる。
  3. 必要なTenant名を把握している。
  4. New-VcfOAuthSecurityContextが認証コンテキストを返す。
  5. その認証コンテキストで対象コンポーネントへ接続できる。

IgnoreSslValidationErrorsはリファレンス上の任意パラメータとして確認できますが、本番の主線に置くべきではありません。検証で一時的に使う場合でも、最終的には証明書チェーンを整える方針に戻してください。

4. PowerCLI 9.1の導入状況

2026年5月25日のVCF 9.1プログラマブル基盤の記事では、VCF PowerCLI 9.1の新機能として、VMware.Vcf.SsoモジュールのNew-VcfOAuthSecurityContext、Connect-VIServer、Connect-NsxServer、Connect-VcfOpsServerへの認証関連パラメータが説明されています。

ただし、運用端末やジョブ実行環境が本当にVCF PowerCLI 9.1のcmdletを使っているとは限りません。古いモジュール、別端末のPowerShellプロファイル、複数バージョンの混在で、手元では動くがジョブでは動かないことがあります。

ジョブへ載せる前に、実行環境で次の情報をログへ残します。ただし、APIトークンやBearer access tokenは出力しません。

Get-Module -ListAvailable VCF.PowerCLI
Get-Command New-VcfOAuthSecurityContext -Syntax
Get-Command Connect-VIServer -Syntax

ここで残すべきなのは、バージョン、cmdletの有無、接続先ホスト、ジョブID、実行時刻などの非秘密情報です。秘密情報を見せずに、後から「どの環境で、どの認証方式を使ったか」が分かるログを残します。

5. 接続後に何をするか

認証方式を整える目的は、接続そのものではありません。接続後に、棚卸し、監視、設定変更、レポート、容量計画などの作業を安全に実行することです。

たとえば、VCF Operationsへ接続できるようになった後は、管理VMのリソース割り当てや容量計画へ進む読者も多いはずです。その場合は、<a href="https://avgo-watch.blog.mo-gmo.com/avgo-15-vcf-operations-vcenter-nsx-resource-allocation/">VCF OperationsでvCenter Server VMとNSX Manager VMのリソース割り当てを確認する記事</a>が次の確認ポイントになります。

接続テストの成功条件は、次のように分けてください。

成功条件なぜ必要か
認証コンテキストを生成できるAPIトークン、Identity Broker、Tenant、証明書の確認になる
vCenter Serverへ接続できるvSphere側の認証ドメインと権限確認になる
NSX Managerへ接続できるネットワーク管理側の認証横断を確認できる
VCF Operationsへ接続できる運用データ取得や容量計画へつなげられる
秘密情報をログへ出していない本番運用に載せられる最低条件になる

vCenter、NSX、VCF Operationsへの接続フロー

Visual段階的に広げる接続フロー最初から全コンポーネントへ広げず、基準点を作ってから横展開します。
  1. 1APIトークンを準備する

    発行元、権限、保管場所を確認し、実トークンがログや履歴に残らない状態で扱います。

  2. 2認証コンテキストを作る

    `New-VcfOAuthSecurityContext`でIdentity Broker、Tenant、証明書の前提を確認します。

  3. 3vCenter Serverを基準点にする

    `Connect-VIServer`で接続方式、認証ドメイン、権限、取得したい情報を確認します。

  4. 4NSX Managerへ広げる

    VCF PowerCLI 9.1の実環境で使うcmdlet名と認証パラメータを確認してから接続します。

  5. 5VCF Operationsへ広げる

    運用データ取得や容量計画につながる処理を、同じ認証設計の中で確認します。

  6. 6切断とログを確認する

    接続後の切断処理まで含め、APIトークンや認証コンテキストの中身が残っていないかを確認します。

vCenterで認証ドメインや証明書の問題が出る場合は、NSXやVCF Operationsへ進む前に切り分けます。

実際の導入では、いきなり全コンポーネントをつなぐより、段階を分ける方が安全です。最初にAPIトークンを発行し、次にIdentity Brokerで認証コンテキストを作り、vCenter Server、NSX Manager、VCF Operationsの順に接続範囲を広げます。

vCenter Serverを基準点にする

vCenter Serverは、多くのVCF運用で最初に確認する接続先です。Connect-VIServerの公式リファレンスは、VcfApiTokenとVcfOAuthSecurityContextの両方を確認できるため、認証方式の比較にも向いています。

最初の検証では、次の問いに答えます。

  • APIトークン直接利用でvCenterへ接続できるか。
  • New-VcfOAuthSecurityContextで作った認証コンテキストでも接続できるか。
  • どちらの方式でも、取得したいインベントリや権限確認の操作ができるか。
  • 切断処理まで含めて、秘密情報がログへ出ていないか。

ここでうまくいかない場合、NSXやVCF Operationsへ進む前に止めます。vCenterで認証ドメインや証明書の問題が出ている状態で横展開しても、切り分けが難しくなるだけです。

NSX ManagerとVCF Operationsへ広げる

公式ブログでは、VcfOAuthSecurityContextを使ってNSX Managerへ接続する例が示されています。VCF 9.1のプログラマブル基盤記事では、Connect-NsxServerとConnect-VcfOpsServerも、PowerCLI 9.1の認証関連強化の文脈で挙げられています。

ここで重要なのは、古い情報と混同しないことです。NSXのPowerCLI周りでは、過去のモジュール名やcmdlet名が残っている記事もあります。VCF PowerCLI 9.1の環境では、実際に使う端末でGet-Commandを実行し、現在のcmdlet名とパラメータを確認してください。

サンプル値は必ずマスクする

記事、手順書、運用メモに実トークンを書かないのは当然として、ラボ環境のFQDNや組織名も必要以上に残さない方が安全です。

$oauthContext = New-VcfOAuthSecurityContext `
  -IdentityBrokerHostname "vidb.example.local" `
  -ApiToken $apiToken

Connect-VIServer -Server "vc.example.local" -VcfOAuthSecurityContext $oauthContext
Connect-NsxServer -Server "nsx.example.local" -VcfOAuthSecurityContext $oauthContext

VCF Operationsへの接続も含める場合は、自分のPowerCLI環境でConnect-VcfOpsServerの構文を確認し、公式リファレンスやリリースノートと照合してからジョブへ入れてください。

CI/CDとパスワードレス運用に載せるときの考え方

Visual手元検証からジョブ運用までCI/CDへ移す前に、認証失敗時の切り分けとログ方針を決めます。
  1. 手元でcmdletを確認する

    VCF PowerCLI 9.1のcmdlet、Identity Broker到達性、認証コンテキスト生成を管理端末で確認します。

  2. vCenterで基準接続を作る

    vCenter Serverへ接続し、認証ドメイン、権限、証明書、取得したい操作を確認します。

  3. 横断接続を確認する

    NSX ManagerまたはVCF Operationsへ広げ、対象コンポーネントごとの権限差を確認します。

  4. ジョブへ移す

    APIトークンは保護された変数やSecret Manager相当の仕組みに置き、平文の設定ファイルを避けます。

  5. ログと監査で守る

    ジョブID、実行時刻、対象ホスト、接続方式、PowerCLIバージョン、失敗分類を残し、秘密情報は残しません。

リトライやデバッグログを増やすほど、APIトークンやBearer access token相当の情報を出さない設計が重要になります。

VCF PowerCLI 9.1のOAuth 2.0認証は、CI/CDや定期ジョブに向いた変更です。ただし、CI/CDに載せる時点で、認証失敗時のリトライ、秘密情報の取り扱い、監査ログ、権限変更時の失効まで考える必要があります。

まず手元で検証し、次にジョブへ移す

最初からCI/CDに入れると、失敗時に見える情報が限られます。まずは権限のある管理端末で、次の順に確認します。

  1. VCF PowerCLI 9.1のcmdletが見える。
  2. Identity Brokerへ到達できる。
  3. APIトークンから認証コンテキストを作れる。
  4. vCenter Serverへ接続できる。
  5. NSX ManagerまたはVCF Operationsへ接続できる。
  6. 切断し、秘密情報がログに残っていないことを確認する。

その後、同じ確認をジョブ実行環境へ移します。ジョブ環境では、対話入力が使えないことが多いため、APIトークンを保護された変数やSecretとして渡す方式を決めます。

失敗を分けて検出する

ジョブでは「接続に失敗しました」だけでは足りません。少なくとも、次の失敗を分けて検出できるようにします。

失敗代表的な確認先
PowerCLIの構文が古いモジュールのバージョン、Get-Command結果
Identity Brokerへ到達できない名前解決、ネットワーク、証明書
APIトークンが無効期限切れ、失効、発行元、権限
Tenantや認証ドメインが違うID管理チーム、VCF SSO設定
接続後の操作が拒否されるロール、スコープ、対象コンポーネントの権限

ログと監査で守る

ログには、秘密情報ではなく、後から運用判断に使える情報を残します。

残してよい情報の例は、ジョブID、実行時刻、対象ホスト、接続方式、接続成功/失敗、使用したPowerCLIバージョン、失敗分類です。残してはいけない情報は、APIトークン、Bearer access token、認証コンテキストの中身、セッションシークレット、マスクしていないユーザー識別子です。

デバッグ時にWrite-Host $apiTokenのような出力を入れると、CI/CDのログ保管期間いっぱい秘密情報が残る可能性があります。接続トラブルを解くためにログを増やすときほど、何を出してはいけないかを先に決めてください。

VCF 9.1の他の自動化と合わせて見る

VCF PowerCLI 9.1のOAuth 2.0認証は、単独の小さな機能ではありません。VCF 9.1ではAPI-first、SDK、PowerCLI、Terraform Providerなど、プログラマブルな運用の文脈が強くなっています。認証が整理されると、棚卸し、アップグレード前チェック、ネットワーク設定、エッジ展開、容量確認のような作業を、より安全に自動化しやすくなります。

VCF Edge 9.1のように拠点展開や自動化が絡むテーマでは、認証の設計が後回しになると、現場の展開手順が属人化します。エッジ展開の前提確認は、<a href="https://avgo-watch.blog.mo-gmo.com/avgo-14-vcf-edge-91-ztp-check/">VCF Edge 9.1のZero Touch Provisioning導入前チェック</a>も参照してください。

まとめ：単体検証は直接トークン、横断運用は認証コンテキストを基本線にする

Visual方式選択と見落としやすい確認点何を自動化し、どこまで横断するかで基本線を決めます。
項目内容見方
vCenter単体の短い検証`VcfApiToken`直接利用から始め、認証ドメイン、構文、証明書、権限、トークン保管を確認します。
複数コンポーネントの横断運用`VcfOAuthSecurityContext`を基本線にし、Identity Broker、Tenant、各接続先の権限を分けて確認します。
証明書と時刻同期認証情報が正しくても、TLSや時刻の問題で接続が失敗する可能性があります。
APIトークン保管パスワードレス化しても、トークンがログや履歴に残れば同じ種類のリスクが残ります。
失効手順担当変更、端末紛失、権限変更、漏えい時にすぐ止められる手順を持ちます。

方式選択は一度で固定せず、単体検証から横断運用へ進む段階で見直します。

VCF PowerCLI 9.1のOAuth 2.0認証を導入するときは、最初に「どの接続方式を使うか」を決めるより、「何を自動化し、どこまで横断するか」を決める方が失敗しにくくなります。

vCenter Serverだけへ短く接続する検証なら、VcfApiToken直接利用から始めるのは自然です。対象vCenterの認証ドメイン、PowerCLI 9.1の構文、証明書、権限、トークン保管を確認してください。

複数コンポーネントへ接続するジョブ、共通関数化したスクリプト、CI/CDや定期実行では、New-VcfOAuthSecurityContextで認証コンテキストを作り、vCenter、NSX、VCF Operationsへ広げる設計を基本線にします。トークン交換とコンポーネント接続を分けることで、失敗時の切り分けも楽になります。

最後にもう一度、導入前の確認項目を短くまとめます。

確認項目見落とすと起きること
VCF SSO認証ドメイン正しいトークンに見えても対象コンポーネントで拒否される
Identity Broker hostnameNew-VcfOAuthSecurityContextの段階で失敗する
Tenantマルチテナント構成で別の認証文脈になる
証明書と時刻同期認証情報ではなくTLSや時刻の問題で失敗する
APIトークン保管パスワードレス化したつもりでも秘密情報がログに残る
失効手順担当変更や漏えい時に止められない

本サイトはBroadcom Inc.および関係会社とは非提携です。公式手順や仕様は、必ずBroadcom/VMwareの一次情報で確認してください。

次に読むなら

Broadcomの公式発表、VCF 9.1の技術更新、PowerCLIやAPIまわりの変更を継続して追う場合は、<a href="https://avgo-watch.blog.mo-gmo.com/newsletter/">ニュースレター</a>で更新通知を受け取れます。本文の判断材料を読んだ後の補助導線として使ってください。

更新履歴

Visual確認した一次情報の流れ公開時点で参照した公式情報と、記事の確認日を整理します。
  1. 2026年5月5日

    BroadcomがVMware Cloud Foundation 9.1を発表し、API-firstや自動化の文脈が強まりました。

  2. 2026年5月25日

    VCF 9.1のプログラマブル基盤記事で、VCF PowerCLI 9.1の認証関連強化が説明されました。

  3. 2026年6月1日

    VCF PowerCLI 9.1でのOAuth 2.0認証手順が、公式ブログで公開されました。

  4. 2026年6月2日

    Broadcom DeveloperのPowerCLIリファレンスと公式ブログを確認し、記事を更新しました。

仕様やリファレンスは更新されるため、実環境へ適用する前に公式ページで再確認してください。

  • 2026年6月2日: VMware Cloud Foundation Blog、Broadcom Developer PowerCLI Reference、Broadcom Newsの一次情報を確認し、VCF PowerCLI 9.1のOAuth 2.0認証について整理しました。

次に読むなら

参照した主な情報源

  • VMware Cloud Foundation Blog, "OAuth 2.0 Authentication Using VMware Cloud Foundation PowerCLI 9.1"

https://blogs.vmware.com/cloud-foundation/2026/06/01/oauth-2-0-authentication-using-vmware-cloud-foundation-powercli-9-1/ 確認日: 2026年6月2日

  • Broadcom Developer, "New-VcfOAuthSecurityContext Command | VMware PowerCLI Reference"

https://developer.broadcom.com/powercli/latest/vmware.vcf.sso/commands/new-vcfoauthsecuritycontext 確認日: 2026年6月2日

  • Broadcom Developer, "Connect-VIServer Command | VMware PowerCLI Reference"

https://developer.broadcom.com/powercli/latest/vmware.vimautomation.core/commands/connect-viserver 確認日: 2026年6月2日

  • VMware Cloud Foundation Blog, "Unlocking the Full Potential of Programmable Infrastructure with VMware Cloud Foundation 9.1 – New Features and Capabilities"

https://blogs.vmware.com/cloud-foundation/2026/05/25/unlocking-the-full-potential-of-programmable-infrastructure-with-vmware-cloud-foundation-9-1-new-features-and-capabilities/ 確認日: 2026年6月2日

  • Broadcom News, "Broadcom Announces VMware Cloud Foundation 9.1, Enabling Secure and Cost-Effective Infrastructure for Production AI"

https://news.broadcom.com/emea/releases/broadcom-announces-vmware-cloud-foundation-9-1 確認日: 2026年6月2日

  • Broadcom Developer, "PowerCLI"

https://developer.broadcom.com/powercli 確認日: 2026年6月2日