Azure Kubernetes Service（AKS）の API サーバーをインターネットに公開したまま運用している場合、まず確認すべきなのが API Server Authorized IP Ranges です。これは、kubectl や CI/CD ツールなどが AKS の API サーバーへ接続できる送信元 IP アドレスを、指定した IP アドレスまたは CIDR に限定する機能です。結論から言えば、本番環境では「管理者の固定出口 IP」「VPN・ファイアウォール・NAT Gateway の出口 IP」「CI/CD 基盤の出口 IP」だけを許可し、それ以外からの API サーバー接続を遮断する設計が基本になります。
この記事では、2026年7月3日時点で確認すべき Azure 公式情報をもとに、AKS の API Server Authorized IP Ranges の役割、影響範囲、設定変更時の注意点、移行期限に関係する確認事項、管理者が実務で見るべきチェックポイントを整理します。なお、Microsoft Learn の当該ページ上では最終更新日が 2025年12月30日と表示されています。設定値やサポート条件は変更される可能性があるため、実作業前には必ず最新の Microsoft Learn と対象クラスターの状態を確認してください。(Microsoft Learn)
API Server Authorized IP Ranges とは
API Server Authorized IP Ranges は、AKS のコントロールプレーンにある Kubernetes API サーバーへアクセスできる送信元 IP 範囲を制限する機能です。AKS の API サーバーは、kubectl、Kubernetes ダッシュボード、CI/CD パイプライン、運用自動化ツールなどがクラスターを操作する入口になります。Microsoft Learn では、AKS の API サーバーには既定でパブリック IP アドレスが割り当てられ、Kubernetes RBAC または Azure RBAC でアクセス制御できると説明されています。(Microsoft Learn)
重要なのは、API Server Authorized IP Ranges は RBAC の代替ではなく、ネットワークレベルの入口制御だという点です。RBAC は「認証された利用者が何をできるか」を制御します。一方、API Server Authorized IP Ranges は「そもそもどのネットワークから API サーバーへ到達できるか」を制御します。
たとえば、管理者アカウントの資格情報が漏えいした場合でも、攻撃者の接続元 IP が承認済み範囲に含まれていなければ API サーバーへの要求はブロックされます。Microsoft Learn でも、承認済み IP 範囲に含まれていない IP アドレスからの API サーバー要求はブロックされ、ルールの反映には最大 2 分かかる場合があるとされています。(Microsoft Learn)
今回の更新ポイントとして押さえるべき要点
今回確認すべきポイントは、「新しいコマンドを覚えること」よりも、AKS 管理者が API サーバーの公開範囲をどう設計し直すかです。特にグローバル環境では、拠点、VPN、クラウド開発環境、GitHub Actions や Azure DevOps などの CI/CD、運用自動化基盤が複数リージョンに分散していることが多く、許可する IP 範囲の棚卸しが重要になります。
| 確認項目 | 管理者が見るべきポイント |
|---|---|
| API サーバーの公開範囲 | どの IP/CIDR から kubectl や自動化処理が実行されるか |
| 許可すべき IP | 管理端末の出口 IP、VPN、Azure Firewall、NAT Gateway、CI/CD の出口 IP |
| 避けるべき設定 | 広すぎる CIDR、個人宅の動的 IP を恒久登録、既存範囲を消してしまう更新 |
| 代替策 | Private Cluster、API Server VNet Integration、ジャンプボックス |
| 移行・期限 | API Server Authorized IP Ranges 自体に個別の移行期限は示されていないが、Basic Load Balancer のサポート終了は別途確認が必要 |
Microsoft Learn では、許可すべき IP 範囲として、クラスターのエグレス IP アドレス、つまりファイアウォール、NAT Gateway、アウトバウンド種類に応じた出口アドレス、およびクラスターを管理するネットワーク範囲を含めることが推奨されています。(Microsoft Learn)
影響範囲：誰の作業が止まる可能性があるか
API Server Authorized IP Ranges を有効化または更新すると、AKS のワークロードそのものよりも、クラスターを操作する人・ツールに影響が出ます。たとえば、既存のアプリケーション Pod が動作していても、管理端末や CI/CD の IP が許可範囲から外れていると、デプロイ、ロールバック、ログ確認、スケール操作ができなくなります。
影響を受けやすい対象は次のとおりです。
| 対象 | 想定される影響 | 事前確認 |
|---|---|---|
| 開発者・運用者の端末 | kubectl get pods などが失敗する | VPN 接続時の出口 IP を確認する |
| CI/CD パイプライン | デプロイや Helm 実行が失敗する | Azure DevOps や GitHub Actions の出口 IP を整理する |
| 運用自動化 | バッチ処理、監視連携、証明書更新処理が失敗する | 実行基盤の NAT / Firewall の出口 IP を確認する |
| ジャンプボックス | 管理経路が遮断される | ジャンプボックスが通るネットワーク出口を確認する |
| 複数リージョン運用 | 一部拠点だけ接続できない | 拠点ごとの固定 IP または集約出口を確認する |
Microsoft Learn では、開発端末、ツール、自動化から API サーバーへアクセスする場合、それらの IP アドレスを AKS クラスターの承認済み IP 範囲に追加する必要があると説明されています。また、ファイアウォールの仮想ネットワーク内にジャンプボックスを置く構成も選択肢として示されています。(Microsoft Learn)
設定前に確認すべき制限事項
API Server Authorized IP Ranges は便利な機能ですが、すべての AKS 構成で使えるわけではありません。特に、既存クラスターや古いネットワーク構成を持つ環境では、先に前提条件を確認する必要があります。
| 制限・条件 | 内容 | 実務での判断 |
|---|---|---|
| Load Balancer SKU | 2019年10月以降に作成された Standard SKU Load Balancer のクラスターでサポート | 本番は Standard SKU 前提で設計する |
| Private Cluster | この機能は Private Cluster では使用できない | Private Cluster では別の接続設計を使う |
| Node public IP | Node public IP を使うノードプールでは public IP prefix を使い、その prefix を承認済み範囲に追加する必要がある | ノード単位の個別 IP 管理を避ける |
| 登録可能な範囲数 | 承認済み IP 範囲は最大 200 個 | 200 個を超える場合は API Server VNet Integration を検討 |
| 反映時間 | ルール反映に最大 2 分かかる場合がある | 更新直後の疎通確認で早合点しない |
Microsoft Learn では、API Server Authorized IP Ranges は Standard SKU Load Balancer の条件、Private Cluster では使用不可、最大 200 個までという制限が明記されています。200 個を超える場合は、最大 2,000 個の承認済み IP 範囲をサポートする API Server VNet Integration の利用が選択肢として示されています。(Microsoft Learn)
移行期限：この機能自体より Basic Load Balancer の状態に注意
API Server Authorized IP Ranges 自体について、Microsoft Learn の該当ページでは個別の移行期限は示されていません。ただし、関連して必ず確認すべきなのが AKS クラスターの Load Balancer SKU です。
Microsoft Learn では、AKS は 2025年9月30日以降 Basic Load Balancer をサポートしないと説明しており、既存デプロイは Standard Load Balancer へアップグレードすることが推奨されています。移行時にはダウンタイムが発生し、開始後のロールバックはできず、Basic IP は Standard IP に移行される一方で、アウトバウンドルール用に新しいパブリック IP が作成される場合があります。(Microsoft Learn)
つまり、管理者が確認すべき順序は次のとおりです。
- 対象 AKS クラスターが Basic Load Balancer を使っていないか確認する
- Basic の場合は、API Server Authorized IP Ranges の設定だけでなく、Standard Load Balancer への移行方針を決める
- 移行時のダウンタイム、Webhook、KMS、アウトバウンド IP 変更の影響を事前に確認する
- Standard 化後、API Server Authorized IP Ranges を本番運用に合わせて再設計する
既存の Basic Load Balancer クラスターでは、単に IP 制限を追加するだけではなく、サポート状態、移行可否、再作成・ブルーグリーン移行の必要性まで含めて判断する必要があります。Microsoft Learn の Basic Load Balancer アップグレード手順では、az aks update --load-balancer-sku=Standard による移行と、移行後に Load Balancer 種別、Pod、Service の状態を確認する流れが示されています。(Microsoft Learn)
現在の設定を確認する方法
既存クラスターで API Server Authorized IP Ranges がどう設定されているかは、Azure CLI で確認できます。Microsoft Learn では、az aks show の --query apiServerAccessProfile.authorizedIpRanges を使って既存の承認済み IP 範囲を取得する方法が紹介されています。(Microsoft Learn)
az aks show \
--resource-group <resource-group> \
--name <cluster-name> \
--query apiServerAccessProfile.authorizedIpRanges \
-o table確認結果が空、または広い CIDR になっている場合は、誰でも到達できる状態に近い可能性があります。反対に、特定の IP だけが登録されている場合は、CI/CD や運用自動化の出口 IP が含まれているかを確認してください。
PowerShell では、Get-AzAksCluster で ApiServerAccessProfile を確認できます。Microsoft Learn でも同様の確認方法が示されています。(Microsoft Learn)
Get-AzAksCluster `
-ResourceGroupName <resource-group> `
-Name <cluster-name> |
Select-Object -ExpandProperty ApiServerAccessProfile既存クラスターで承認済み IP 範囲を更新する方法
既存クラスターの承認済み IP 範囲は、az aks update の --api-server-authorized-ip-ranges で更新します。複数の IP 範囲はカンマ区切りで指定します。(Microsoft Learn)
az aks update \
--resource-group <resource-group> \
--name <cluster-name> \
--api-server-authorized-ip-ranges 203.0.113.10/32,198.51.100.0/24ここで最も失敗しやすいのは、追加のつもりで実行したら既存の IP 範囲を置き換えてしまうことです。Microsoft Learn では、新しい IP アドレスを追加する例について、既存の IP アドレスもコマンドに含める必要があり、含めない場合は追加ではなく置き換えになると注意されています。(Microsoft Learn)
実務では、次の流れで作業すると安全です。
| 手順 | 作業内容 | 目的 |
|---|---|---|
| 1 | 現在の承認済み IP 範囲を取得 | 既存設定の消失を防ぐ |
| 2 | 追加・削除する IP をレビュー | 管理者、CI/CD、監視の接続元を確認 |
| 3 | 全範囲を明示して更新 | 置き換え事故を防ぐ |
| 4 | 2 分程度待って疎通確認 | 反映遅延を考慮 |
| 5 | 別経路から復旧できるか確認 | 誤設定時のロックアウト対策 |
0.0.0.0/32 は「全許可」ではない
AKS の API Server Authorized IP Ranges で特に誤解されやすいのが 0.0.0.0/32 です。一般的なネットワーク設定では 0.0.0.0/0 が「すべての IPv4」を意味するため、0.0.0.0/32 も危険な全許可のように見えるかもしれません。
しかし Microsoft Learn では、0.0.0.0/32 は AKS に対して「Standard SKU Load Balancer のアウトバウンドパブリック IP のみを API サーバーへアクセス可能にする」特別な値として説明されています。追加のクライアント IP 範囲を許可する既定動作を無効にし、クラスター自身のアウトバウンド IP のみに制限する用途で使われます。(Microsoft Learn)
az aks create \
--resource-group <resource-group> \
--name <cluster-name> \
--vm-set-type VirtualMachineScaleSets \
--load-balancer-sku standard \
--api-server-authorized-ip-ranges 0.0.0.0/32 \
--generate-ssh-keysこの設定は、外部管理端末から直接 kubectl で操作する運用には向きません。クラスター内の自動化や、決められたジャンプボックス経由での運用を前提にする場合に検討します。
無効化する方法と注意点
API Server Authorized IP Ranges を無効化するには、空の範囲を指定します。Microsoft Learn では、Azure CLI では --api-server-authorized-ip-ranges ""、PowerShell では -ApiServerAccessAuthorizedIpRange '' を指定する方法が示されています。(Microsoft Learn)
az aks update \
--resource-group <resource-group> \
--name <cluster-name> \
--api-server-authorized-ip-ranges ""ただし、本番環境での無効化は慎重に扱うべきです。無効化すると、RBAC や Entra ID の認証が残っていたとしても、API サーバーへのネットワーク到達範囲が広がります。障害対応の一時措置として無効化する場合でも、作業チケット、期限、復旧手順、再有効化後の疎通確認までセットで管理してください。
許可する IP 範囲の決め方
許可する IP 範囲は、「人」ではなく「経路」で整理すると失敗しにくくなります。たとえば、管理者 A さんの自宅 IP を直接登録するより、会社 VPN や Azure Firewall の出口 IP を登録した方が、退職・異動・端末変更に強い設計になります。
| 利用シーン | 推奨される許可対象 | 避けたい設定 |
|---|---|---|
| 社内運用 | VPN またはゼロトラスト基盤の固定出口 IP | 個人宅の動的 IP を恒久登録 |
| Azure 内の運用基盤 | Azure Firewall、NAT Gateway、ジャンプボックスの出口 IP | VM ごとの一時的な Public IP |
| CI/CD | パイプライン実行基盤の固定出口 IP | 変動する共有ランナーの広範な IP を無条件許可 |
| グローバル拠点 | 拠点別の固定出口 IP を最小限登録 | 国単位・クラウド全体の広い CIDR |
| 緊急対応 | 期限付きで一時 IP を追加 | 追加後に削除しない |
AKS と Azure DevOps を統合する場合は、Microsoft Learn でも Azure DevOps 側で許可すべき IP アドレスの確認先が案内されています。CI/CD の出口 IP は変わることがあるため、固定化できない場合は、セルフホステッドエージェントを固定出口のネットワークに置く設計も検討してください。(Microsoft Learn)
Private Cluster や API Server VNet Integration との使い分け
API Server Authorized IP Ranges は、パブリック API サーバーを使いながら到達元を絞る機能です。より厳格に閉域化したい場合は、Private Cluster や API Server VNet Integration も候補になります。
| 選択肢 | 向いているケース | 注意点 |
|---|---|---|
| API Server Authorized IP Ranges | パブリック API サーバーを使いつつ、接続元を絞りたい | Private Cluster では使用不可。最大 200 範囲 |
| Private Cluster | API サーバーをパブリックに出したくない | DNS、踏み台、VNet 接続設計が必要 |
| API Server VNet Integration | API サーバーとノード間通信をプライベートネットワークに寄せたい、IP 範囲数が多い | 有効化後に戻せない制約や再起動影響を確認する |
| ジャンプボックス | 運用経路を一か所に集約したい | 踏み台自体の認証・監査・更新管理が必要 |
Microsoft Learn では、API Server VNet Integration により API サーバーエンドポイントを AKS の VNet 内の委任サブネットへ投影し、API サーバーとノードプール間のトラフィックをプライベートネットワーク上に維持できると説明されています。また、AKS Automatic では API Server VNet Integration が事前構成され、AKS Standard では作成時または既存クラスター更新時に明示的に有効化する機能とされています。(Microsoft Learn)
一方、既存 AKS Standard クラスターに API Server VNet Integration を有効化する場合は注意が必要です。Microsoft Learn では、この機能は一方向の変更で、いったん有効化すると無効化できず、手動再起動が必要で、API サーバーの IP アドレスが変わる可能性があると説明されています。(Microsoft Learn)
サービス タグ利用はプレビュー扱いに注意
AKS では、API Server Authorized IP Ranges にサービス タグを使うプレビュー機能も用意されています。サービス タグを使うと、個別の IP アドレスや CIDR を手動管理する代わりに、定義済みのサービス タグで API サーバーの承認範囲を指定できます。(Microsoft Learn)
ただし、Microsoft Learn では AKS のプレビュー機能はセルフサービス・オプトインで提供され、SLA や限定保証の対象外であり、本番利用を目的としたものではないと説明されています。また、--api-server-authorized-ip-ranges パラメーターで指定できるサービス タグは 1 つだけという制限もあります。(Microsoft Learn)
本番環境では、サービス タグをすぐに標準化するのではなく、検証環境で運用負荷や許可範囲の広がりを確認してから採用判断するのが安全です。
グローバル環境での実務チェックリスト
グローバル向けに AKS を運用している場合、API Server Authorized IP Ranges はセキュリティ部門だけでなく、SRE、ネットワーク、ID 管理、開発チームの合意が必要です。特に、拠点ごとの出口 IP、リージョンごとの NAT、CI/CD の実行場所が分散している場合は、設定変更による作業停止が起きやすくなります。
| チェック項目 | 確認内容 |
|---|---|
| クラスター一覧 | 全 AKS クラスターの API Server Authorized IP Ranges 設定を棚卸ししたか |
| Load Balancer SKU | Basic Load Balancer が残っていないか |
| 管理経路 | 管理者は VPN、ジャンプボックス、固定出口 IP のどれを使うか |
| CI/CD | デプロイ実行元の出口 IP が固定されているか |
| 監視・自動化 | 証明書更新、スケール処理、GitOps などの実行元を確認したか |
| 緊急時対応 | 誤設定時に復旧できる管理経路を用意したか |
| 変更管理 | 追加 IP、削除 IP、期限付き IP をチケットで管理しているか |
| 監査 | 広すぎる CIDR や不要になった IP を定期削除しているか |
特に見落としやすいのは、GitOps、監視ツール、証明書更新ツールなど「人が直接使っていないが API サーバーへ接続している仕組み」です。管理端末だけを許可してしまうと、アプリのデプロイはできても自動同期や運用処理が止まる可能性があります。
設定変更時のよくある失敗
既存の IP 範囲を消してしまう
az aks update --api-server-authorized-ip-ranges は、指定した範囲へ更新する操作です。新しい IP だけを指定すると、既存の許可範囲が残らない場合があります。Microsoft Learn でも、既存 IP を含めないと追加ではなく置き換えになると注意されています。(Microsoft Learn)
対策は、変更前に必ず現在値を取得し、追加後の全リストをレビューしてから適用することです。
動的 IP を恒久的に登録する
自宅回線、モバイル回線、共有オフィスの出口 IP は変わることがあります。動的 IP を恒久登録すると、ある日突然アクセスできなくなるか、逆に使われなくなった IP 範囲を放置することになります。管理者アクセスは VPN や固定出口 IP に集約しましょう。
反映遅延を障害と誤認する
Microsoft Learn では、ルール反映に最大 2 分かかる場合があるとされています。(Microsoft Learn) 更新直後に接続できない場合でも、すぐに再変更を重ねるのではなく、少し待ってから複数経路で疎通を確認する方が安全です。
Private Cluster と同じ感覚で設計する
API Server Authorized IP Ranges は、パブリック API サーバーに対する接続元制限です。Private Cluster とは性質が異なります。Microsoft Learn でも、この機能は Private Cluster では使用できないと明記されています。(Microsoft Learn) 閉域化が必須の環境では、Private Cluster や API Server VNet Integration を含めた再設計が必要です。
CI/CD の出口 IP を後回しにする
人の kubectl 接続だけ確認して、CI/CD の出口 IP を登録し忘れるケースがあります。これにより、手元では操作できるのに本番デプロイだけ失敗する状態になります。変更前の段階で、すべてのデプロイ経路を洗い出してください。
管理者が今すぐ行うべき確認
まずは、すべての AKS クラスターで次の 3 点を確認してください。
- API Server Authorized IP Ranges が未設定または広すぎる CIDR になっていないか
- Basic Load Balancer を使っている古い AKS クラスターが残っていないか
- 管理端末、VPN、Azure Firewall、NAT Gateway、CI/CD、監視・自動化の出口 IP が整理されているか
そのうえで、本番クラスターでは「固定出口 IP に集約する」「許可範囲を最小化する」「変更時に既存範囲を消さない」「Private Cluster や API Server VNet Integration との使い分けを決める」という順序で対応すると安全です。
API Server Authorized IP Ranges は、単体では小さなネットワーク設定に見えます。しかし、AKS の API サーバーはクラスター管理の入口であり、ここを広く公開したままにするか、必要な経路だけに絞るかでセキュリティリスクは大きく変わります。まずは現状の承認済み IP 範囲を取得し、不要な範囲を削除できる状態まで棚卸しすることが、最初に取るべき実務アクションです。
コメント