Azure BastionでAKSプライベートクラスターに接続する方法｜Preview更新ポイントと管理者の確認事項

AKSプライベートクラスターへの管理接続で、VPNや踏み台VMの準備が重く感じられる場合は、Azure Bastion のネイティブクライアントトンネリングが新しい選択肢になります。今回の「Connect to AKS Private Cluster Using Azure Bastion (Preview)」は、AKS API サーバーをインターネットへ公開せず、Azure CLI と kubectl を使ってローカル端末から安全に接続するための手順を示した公式情報です。結論として、既存環境をすぐ移行しなければならない変更ではありませんが、プライベートAKSの運用者は、Bastion の SKU、Native Client Support、RBAC、VNet/DNS 到達性、Preview機能としての制限を確認しておくべきです。MicrosoftDocs の履歴では、該当ドキュメントは 2026年7月1日の自動公開に含まれています。(GitHub)

Azure BastionでAKSプライベートクラスターに接続できるようになる意味

AKSプライベートクラスターは、API サーバーをパブリックインターネットへ直接公開せず、プライベートネットワーク内で管理アクセスを完結させる構成です。Microsoft Learn では、AKS のプライベートクラスターでは API サーバーが内部IPアドレスを持ち、API サーバーとノードプール間の通信をプライベートネットワークに保てると説明されています。(Microsoft Learn)

一方で、API サーバーが外部から見えないということは、管理者の端末から kubectl を実行する経路も別途用意しなければならないということです。これまでは、代表的に次のような方法が使われてきました。

接続方式	向いている場面	注意点
VPN	社内・開発者端末から継続的に接続したい	ネットワーク設計、認証、端末配布の運用が必要
ExpressRoute	大規模企業や基幹系で専用線品質が必要	コストと導入リードタイムが大きい
踏み台VM + Azure Bastion	既存の運用端末をAzure内に置きたい	踏み台VMのOS更新、権限管理、冗長化が必要
`az aks command invoke`	一時的にコマンドを実行したい	対話的な長時間作業やローカルツール連携には不向き
Azure Bastion native client tunneling	ローカル端末のCLIから直接操作したい	Preview機能であり、本番標準化には検証が必要

今回の更新ポイントは、Azure Bastion を「VMへRDP/SSHするためのサービス」としてだけでなく、「AKSプライベートクラスターの API サーバーへ安全にトンネル接続する入口」として使える点です。公式ドキュメントでは、Azure Bastion の native client tunneling を使い、AKSプライベートクラスターのエンドポイントを公開せずに接続する手順が示されています。(Microsoft Learn)

影響範囲：対象になる管理者と環境

この変更の影響を受けるのは、主に次のようなAzure環境です。

対象	影響
AKSプライベートクラスターを運用している環境	API サーバーへの管理接続方式の選択肢が増える
ハブアンドスポーク構成のAzureネットワーク	Bastion配置VNetとAKS配置VNetの到達性、ピアリング、DNS設計の確認が必要
リモート開発者や運用担当者が多い組織	VPN配布や踏み台VM運用を減らせる可能性がある
API server authorized IP ranges を使うパブリックAKS	BastionのパブリックIPを許可リストへ追加する必要がある場合がある
本番AKSを厳格に管理している組織	Preview機能のため、本番運用の標準経路にするか慎重な判断が必要

特に大きいのは、踏み台VMを常設しなくても、ローカル端末の CLI から AKS に接続できる可能性がある点です。Azure Architecture Center でも、Azure Bastion の native client tunneling は、ジャンプボックスなしでAKSプライベートクラスターへ直接接続でき、ローカル端末のネイティブクライアントツールを使い続けられる方式として説明されています。(Microsoft Learn)

ただし、すべてのAKS環境にそのまま使えるわけではありません。Azure Architecture Center では、この機能は Preview であり、AKS Automatic clusters と network resource group lockdown が有効なクラスターでは Azure Bastion native client tunneling がサポートされないとされています。(Microsoft Learn)

必要な前提条件

公式ドキュメントの手順を実行する前に、管理者は次の条件を確認する必要があります。

確認項目	内容
Azure Bastion	AKSクラスターが存在するVNet、または到達可能なVNetにBastionが必要
Bastion SKU	Standard または Premium SKU が必要
Native Client Support	Bastion の構成で有効化が必要
AKS	対象のAKSクラスターが同一VNetまたは到達可能なVNetに存在すること
RBAC	AKS、Bastion、必要に応じてターゲットVNetへの Reader ロールが必要
クライアント端末	Azure CLI と `kubectl` を使える状態にしておく
DNS/ネットワーク	AKS API サーバーのFQDNへ正しく到達できる経路を確認する

Microsoft Learn の該当ページでは、Bastion は Standard または Premium SKU で、構成設定の Native Client Support が有効である必要があると説明されています。また、AKSクラスター、Bastionリソース、ピアリング先VNetを利用する場合はターゲットVNetに対する Reader ロールが必要です。(Microsoft Learn)

Bastion の native client connection 自体も、Standard SKU が必要な機能として説明されています。既存Bastionを使う場合は、SKUがStandard以上か、Native Client Support が有効かを先に確認してください。(Microsoft Learn)

接続手順の流れ

基本の流れは、Azureにサインインし、AKSの資格情報を取得し、Bastion経由のトンネルを開き、kubectl がそのトンネルを向くように設定する、という順序です。

Azure CLIでサブスクリプションを選択する

複数サブスクリプションを使っている組織では、最初に対象サブスクリプションを明示します。

az login

az account set --subscription <subscription ID>

運用端末に複数テナント・複数サブスクリプションの権限がある場合、ここを曖昧にすると別環境のKUBECONFIGを更新してしまうことがあります。作業ログにサブスクリプションID、リソースグループ名、AKS名、Bastion名を残してから実行すると安全です。

AKSクラスターの資格情報を取得する

次に、対象AKSクラスターの資格情報を取得します。

az aks get-credentials \
  --admin \
  --name <AKSClusterName> \
  --resource-group <ResourceGroupName>

公式手順では --admin を使った例が示されていますが、実運用では常に管理者資格情報を使うべきとは限りません。Microsoft Entra ID 統合や Kubernetes RBAC を使っている環境では、管理者用と通常運用用の接続手順を分け、誰がどの権限で kubectl を実行できるかを明確にしてください。

Azure Bastion経由でAKSへのトンネルを開く

BastionのリソースIDを指定して、AKSクラスターへのトンネルを開きます。

az aks bastion \
  --name <aksClusterName> \
  --resource-group <aksClusterResourceGroup> \
  --admin \
  --bastion <bastionResourceId>

Azure CLI の az aks bastion リファレンスでは、このコマンドは Azure Bastion を使用してマネージドKubernetesクラスターに接続するコマンドとして説明されています。オプションとして、Bastionリソース、既存の kubeconfig パス、ローカルポート番号などを指定できます。(Microsoft Learn)

kubeconfigをBastionトンネル向けに調整する

公式手順では、Bastionトンネルで使われるローカルポートを取得し、KUBECONFIG内の API サーバー接続先を localhost:<port> に向ける例が示されています。

export BASTION_PORT=$(ps aux | sed -n 's/.*--port \([0-9]*\).*/\1/p' | head -1)

sed -i "s|server: https://.*|server: https://localhost:${BASTION_PORT}|" $KUBECONFIG

この作業は便利ですが、既存の kubeconfig を直接書き換える点に注意が必要です。複数クラスターを扱う管理者端末では、作業前に kubeconfig をバックアップするか、検証用に別ファイルを指定する運用にしたほうが安全です。

接続後は、通常の kubectl コマンドでクラスターを操作します。

kubectl get nodes

管理者が確認すべき設定変更

今回の更新は「既存AKSの設定が自動で変わる」タイプの変更ではありません。必要な場合に、管理者がBastion側・権限側・接続端末側の設定を整える変更です。

確認領域	確認すべきこと	実務上の判断基準
Bastion SKU	Standard または Premium か	BasicやDeveloperでは前提を満たさない可能性がある
Native Client Support	有効化されているか	既存Bastionを流用する場合に見落としやすい
VNet到達性	BastionからAKS API サーバーへ到達できるか	同一VNetまたはピアリング済みVNetで設計する
DNS	AKS API サーバーのFQDNを解決できるか	hub-spokeやカスタムDNS環境では特に確認が必要
RBAC	Readerロールが付与されているか	Bastion、AKS、必要に応じてVNetに対して確認
kubeconfig	既存設定を壊さないか	検証時は専用kubeconfigを使う
監査	誰が接続できるか追跡できるか	Entra ID、Azure RBAC、Kubernetes RBACの役割分担を整理
コスト	Bastionの常時課金を把握しているか	検証用Bastionは不要になったら削除する

Azure Bastion はデプロイされた時点から時間単位の課金が開始されるため、検証目的で作成したBastionを放置しないことも重要です。Microsoft Learn の native client connection の説明でも、チュートリアルやテストでデプロイしたBastionは利用後に削除することが推奨されています。(Microsoft Learn)

移行期限はあるのか

現時点で、この更新に伴う強制的な移行期限は示されていません。既存のVPN、ExpressRoute、踏み台VM、az aks command invoke が直ちに使えなくなるという内容でもありません。

むしろ、今回のポイントは「AKSプライベートクラスターへの管理アクセス方式が増えた」と捉えるのが適切です。既存の本番環境では、いきなり標準手順に置き換えるのではなく、次の順序で判断すると安全です。

フェーズ	実施内容
検証	非本番AKSでBastion経由の接続を試す
権限整理	管理者、開発者、監査担当の必要権限を分ける
ネットワーク確認	VNet peering、DNS、NSG、ファイアウォールの影響を確認する
手順化	kubeconfigの扱い、接続終了方法、トラブル時の切り戻しを文書化する
本番判断	Preview制限とサポート範囲を踏まえ、正式運用に組み込むか決める

重要なのは、Preview機能である点です。Azure Architecture Center では、AKSのPreview機能は self-service の opt-in で提供され、SLAや限定保証の対象外であり、サポートは部分的な best-effort になるため、本番用途には適さないと説明されています。(Microsoft Learn)

よくある失敗と対策

BastionのSKUだけを見てNative Client Supportを有効にしていない

StandardまたはPremium SKUであっても、Native Client Support が無効のままだと期待した接続ができません。既存Bastionを使う場合は、Azure PortalのBastionリソースから Configuration を開き、Native Client Support の状態を確認してください。

AKSのDNS解決を軽視している

AKSプライベートクラスターでは、API サーバーのFQDN解決が接続成否を大きく左右します。特にハブアンドスポーク構成、カスタムDNS、オンプレミスDNSフォワーダーを使う環境では、Bastionが配置されたVNetからAKS API サーバーの名前解決ができるかを事前に確認してください。Azure Architecture Center でも、接続問題の確認ポイントとして VNet peering と private DNS zone の virtual network link が挙げられています。(Microsoft Learn)

kubeconfigを直接書き換えて他クラスター操作に影響する

複数AKSクラスターを管理する端末で $KUBECONFIG を直接編集すると、別クラスターのコンテキストや既存の接続設定に影響する可能性があります。検証時は次のように専用ファイルを使う運用が安全です。

export KUBECONFIG=./kubeconfig-aks-bastion-test

そのうえで az aks get-credentials や az aks bastion を実行すれば、通常利用している ~/.kube/config への影響を抑えられます。

Preview機能を本番の唯一の管理経路にしてしまう

Bastion native client tunneling は便利ですが、Previewの段階で本番AKSへの唯一の接続経路にするのはリスクがあります。最低限、既存の緊急アクセス手段として VPN、ExpressRoute、踏み台VM、または az aks command invoke のいずれかを残し、障害時に管理操作が止まらないようにしてください。

パブリックAKSのauthorized IP rangesを更新していない

公式ドキュメントでは、API server authorized IP ranges を使うパブリッククラスターにBastion経由で接続する場合、BastionのパブリックIPアドレスを許可範囲に追加する必要があるとされています。プライベートAKSだけでなく、IP制限付きのパブリックAKSを管理している環境でも確認が必要です。(Microsoft Learn)

実務でのおすすめ活用シーン

Azure BastionによるAKSプライベートクラスター接続は、次のような場面で特に効果があります。

活用シーン	期待できる効果
非本番AKSの保守	VPNを配布せず、短時間の調査や検証をしやすい
グローバル運用チーム	拠点ごとのVPN差異を減らし、Azure RBAC中心にアクセスを整理できる
踏み台VM削減	OS更新、EDR、脆弱性対応、冗長化設計の負担を減らせる
セキュリティ強化	AKS API サーバーを公開せず、管理接続の入口をBastionに寄せられる
障害調査	ローカルの `kubectl`、`helm`、診断スクリプトを使いやすい

ただし、すべてをBastionに寄せるのではなく、用途で使い分けるのが現実的です。たとえば、日常の軽微な確認は Bastion native client tunneling、定型的な単発コマンドは az aks command invoke、大規模な運用作業や常時接続が必要なチームはVPNやExpressRouteを使う、といった整理ができます。

管理者向けチェックリスト

本番環境への適用を検討する前に、次の項目を確認してください。

チェック項目	確認結果
対象AKSが private cluster か、またはIP制限付きpublic clusterか
Bastionが Standard または Premium SKU か
Native Client Support が有効か
BastionからAKS API サーバーへ到達できるVNet設計か
private DNS zone / custom DNS / VNet link が正しく構成されているか
AKS、Bastion、VNetに必要な Reader 権限があるか
`az aks bastion` を実行できる Azure CLI 環境か
kubeconfigを直接上書きしない運用になっているか
Preview機能としてサポート範囲を関係者が理解しているか
障害時の代替接続経路を残しているか

まず検証環境で接続手順を標準化する

「Connect to AKS Private Cluster Using Azure Bastion (Preview)」の更新ポイントは、AKSプライベートクラスターの管理アクセスをよりシンプルにできることです。API サーバーを公開せず、踏み台VMを増やさず、ローカルのCLIから接続できる可能性があるため、セキュリティと運用効率の両面で価値があります。

一方で、Preview機能であり、AKS Automatic clusters や NRG lockdown など未サポート条件もあります。移行期限に追われて対応する変更ではなく、既存のVPN、ExpressRoute、踏み台VM、Run command と比較しながら、自社の運用モデルに合うかを検証する段階です。

管理者はまず、非本番のAKSプライベートクラスターで Bastion StandardまたはPremium、Native Client Support、Reader権限、DNS到達性を確認し、接続手順と切り戻し手順を文書化してください。そのうえで、グローバル運用チームの接続経路削減、踏み台VMの整理、セキュアなAKS管理アクセスの標準化に活用できるかを判断するのが安全です。

この記事を書いた人

佐藤健司

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows／Office（Teams・Excel）からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。

Azure BastionでAKSプライベートクラスターに接続する方法｜Preview更新ポイントと管理者の確認事項

Azure BastionでAKSプライベートクラスターに接続できるようになる意味

影響範囲：対象になる管理者と環境

必要な前提条件

接続手順の流れ

Azure CLIでサブスクリプションを選択する

AKSクラスターの資格情報を取得する

Azure Bastion経由でAKSへのトンネルを開く

kubeconfigをBastionトンネル向けに調整する

管理者が確認すべき設定変更

移行期限はあるのか

よくある失敗と対策

BastionのSKUだけを見てNative Client Supportを有効にしていない

AKSのDNS解決を軽視している

kubeconfigを直接書き換えて他クラスター操作に影響する

Preview機能を本番の唯一の管理経路にしてしまう

パブリックAKSのauthorized IP rangesを更新していない

実務でのおすすめ活用シーン

管理者向けチェックリスト

まず検証環境で接続手順を標準化する

この記事を書いた人

コメント

コメントするコメントをキャンセル

Azure BastionでAKSプライベートクラスターに接続する方法｜Preview更新ポイントと管理者の確認事項

Azure BastionでAKSプライベートクラスターに接続できるようになる意味

影響範囲：対象になる管理者と環境

必要な前提条件

接続手順の流れ

Azure CLIでサブスクリプションを選択する

AKSクラスターの資格情報を取得する

Azure Bastion経由でAKSへのトンネルを開く

kubeconfigをBastionトンネル向けに調整する

管理者が確認すべき設定変更

移行期限はあるのか

よくある失敗と対策

BastionのSKUだけを見てNative Client Supportを有効にしていない

AKSのDNS解決を軽視している

kubeconfigを直接書き換えて他クラスター操作に影響する

Preview機能を本番の唯一の管理経路にしてしまう

パブリックAKSのauthorized IP rangesを更新していない

実務でのおすすめ活用シーン

管理者向けチェックリスト

まず検証環境で接続手順を標準化する

この記事を書いた人

関連記事

コメント

コメントする コメントをキャンセル

コメントするコメントをキャンセル