Visual Studio Code の AKS 拡張機能で Azure Container Registry（ACR）を AKS クラスターに Attach する機能は、コンテナーイメージを AKS から安全に取得できるようにするための実務向け手順です。結論から言うと、2026年7月3日相当の更新で確認すべき中心は「新しい操作手順」ではなく、ドキュメント上の分類メタデータ更新と、ACR 連携時の権限設計を正しく理解することです。GitHub の公式履歴では、該当ドキュメントに ms.subservice: aks-developer が追加され、本文は変更されていないことが示されています。(GitHub)
この記事では、Visual Studio と表現されることがあるこの話題を、実際の対象である Visual Studio Code の Azure Kubernetes Service（AKS）拡張機能として整理します。ACR を Attach すると何が変わるのか、どの権限が必要なのか、管理者が確認すべき影響範囲、移行期限の有無、失敗しやすいポイントまで、実務で確認できる形で解説します。
Visual Studio Code の AKS 拡張機能で ACR を Attach する機能の概要
この機能は、Visual Studio Code から AKS クラスターと Azure Container Registry を関連付け、AKS 側が ACR 上のコンテナーイメージを取得できるようにするための手順です。Microsoft Learn の該当ページでは、ACR、AKS クラスター、Visual Studio Code 用 AKS 拡張機能が前提条件として示されています。(Microsoft Learn)
注意したいのは、ここでいう Attach は「アプリケーションを自動でデプロイする」「Docker イメージをビルドする」「ACR に push する」という意味ではないことです。主な目的は、AKS が ACR からイメージを pull できる認証・認可の関係を作ることです。AKS と ACR の統合では、通常、AKS のエージェントプールに関連付く Microsoft Entra 管理 ID に AcrPull ロールを割り当てる形で権限が構成されます。(Microsoft Learn)
たとえば、Kubernetes の Deployment で次のようなイメージを指定している場合を考えます。
image: myregistry.azurecr.io/webapi:v1このとき AKS 側に ACR への pull 権限がなければ、Pod は ImagePullBackOff や ErrImagePull になりやすくなります。Visual Studio Code の AKS 拡張機能から Attach する目的は、この「AKS が ACR からイメージを取得できない」という典型的なつまずきを減らすことにあります。
2026年7月3日更新ポイントの読み方
2026年7月3日相当の更新ポイントは、機能そのものの大幅変更ではなく、公式ドキュメントの分類情報の更新として見るのが適切です。GitHub の履歴では、2026年7月2日 15:26:09 -0700 にコミットが行われており、日本時間では2026年7月3日に相当します。このコミットでは、AKS 関連ドキュメントの所有者情報や機能タグ、サブサービス分類が整理され、該当ファイルには ms.subservice: aks-developer が追加されています。(GitHub)
一方で、Microsoft Learn の表示上は該当ページの Last updated が 2024年8月1日となっているため、記事化する際は「2026年7月3日に本文手順が刷新された」と断定しない方が安全です。公式リポジトリ上の更新内容では「front-matter only; no article body content changed」とされており、本文手順そのものは変わっていません。(Microsoft Learn)
| 確認項目 | 今回の読み取り | 実務での対応 |
|---|---|---|
| 機能変更 | 本文手順の変更は確認できない | 既存の Attach 手順を継続してよい |
| ドキュメント分類 | ms.subservice: aks-developer が追加 | 開発者向け AKS 機能として整理されたと見る |
| 設定変更 | ACR・AKS・VS Code 拡張機能の前提は継続 | 既存環境の構成変更は原則不要 |
| 移行期限 | この更新に伴う移行期限は確認できない | ただし ACR の権限方式や ID 変更時は個別確認が必要 |
| 管理者の重点 | 権限、ID、ABAC、ネットワーク、検証 | GUI 操作だけで完了と判断しない |
Attach で実際に入力する情報
Visual Studio Code の AKS 拡張機能では、ACR を AKS クラスターに Attach する画面へ、コマンドパレットまたは Kubernetes ビューからアクセスできます。コマンドパレットでは Ctrl+Shift+P を押し、サブスクリプション、ACR のリソースグループ、コンテナーレジストリ、AKS クラスターのリソースグループ、クラスターを選択して Attach を実行します。成功すると緑のチェックマークが表示される流れです。(Microsoft Learn)
Kubernetes ビューから実行する場合は、Clouds > Azure > サブスクリプション > Automated Deployments 配下で対象クラスターを右クリックし、Attach ACR to Cluster を選択します。入力する項目はコマンドパレット経由と同じです。(Microsoft Learn)
| 入力項目 | 確認すべきポイント | よくあるミス |
|---|---|---|
| Subscription | ACR と AKS が存在するサブスクリプションを選ぶ | 開発・本番サブスクリプションを取り違える |
| ACR Resource Group | ACR が配置されているリソースグループを選ぶ | AKS のリソースグループと混同する |
| Container Registry | AKS から pull させたい ACR を選ぶ | 旧環境や検証用 ACR を選んでしまう |
| Cluster Resource Group | AKS クラスターのリソースグループを選ぶ | ノードリソースグループと混同する |
| Cluster | Attach 対象の AKS クラスターを選ぶ | 同名に近いクラスターを誤選択する |
グローバル展開している組織では、リージョン名よりも「サブスクリプション」「リソースグループ」「ACR 名」「AKS クラスター名」の組み合わせで確認する運用にした方が安全です。特に本番・検証・ステージングを複数国で分けている場合、見た目が似たリソース名の誤選択が起きやすくなります。
管理者が押さえるべき権限の考え方
ACR を AKS に Attach する本質は、AKS が ACR からイメージを pull できるようにする権限設定です。Azure CLI の --attach-acr を使う場合、既存の ACR を認可し、管理 IDに適切な AcrPull ロールを構成する流れになります。既存 AKS クラスターに対しては az aks update --attach-acr で Attach できます。(Microsoft Learn)
ただし、すべての ACR で AcrPull だけを見ればよいわけではありません。ABAC が有効な ACR で、ロール割り当てのアクセス許可モードが「RBAC Registry + ABAC Repository Permissions」の場合、az aks --attach-acr による AKS-ACR 統合はサポートされず、AcrPull ではなく Container Registry Repository Reader ロールを手動で割り当てる必要があります。(Microsoft Learn)
| ACR の状態 | 必要な考え方 | 管理者の確認 |
|---|---|---|
| 通常の RBAC ベース | AKS の kubelet ID に AcrPull を付与 | ACR スコープでロールが付いているか確認 |
| ABAC 有効 | Container Registry Repository Reader を検討 | --attach-acr 前提にしない |
| 既存クラスター | az aks update --attach-acr 相当の設定を確認 | 既存 ID にロールが付いているか確認 |
| Terraform 管理 | ロール割り当てを IaC に明記 | 手動 Attach と IaC の差分をなくす |
| 本番環境 | 必要最小限のスコープで付与 | リソースグループ全体ではなく ACR スコープを優先 |
本番環境では、AcrPull を広いリソースグループスコープで付けるより、ACR スコープで割り当てる方が権限を絞りやすくなります。Microsoft Learn でも、本番シナリオではリソースグループではなく Azure Container Registry スコープで AcrPull を割り当てることが示されています。(Microsoft Learn)
事前に確認すべき前提条件
Visual Studio Code から Attach を実行する前に、最低限、ACR、AKS クラスター、AKS 拡張機能がそろっている必要があります。加えて、操作ユーザーにはロール割り当てを作成できる権限が必要です。Microsoft Learn の ACR 統合手順では、サブスクリプションに対する Owner、Azure account administrator、Azure co-administrator、またはロール割り当てに必要な権限が前提として示されています。(Microsoft Learn)
実務では、次の順番で確認すると手戻りを減らせます。
| 確認順 | 確認内容 | 判断基準 |
|---|---|---|
| 1 | Visual Studio Code に AKS 拡張機能が入っているか | Azure の Kubernetes ビューで AKS を参照できる |
| 2 | Azure にサインインしているか | 対象サブスクリプションが表示される |
| 3 | ACR が存在するか | 対象レジストリ名が選択肢に出る |
| 4 | AKS クラスターが存在するか | 対象クラスターが選択肢に出る |
| 5 | 操作ユーザーに権限があるか | Attach 後にロール割り当てが作成される |
| 6 | ACR の権限方式が ABAC か | ABAC の場合は手動ロール割り当てを検討 |
| 7 | ネットワーク制限があるか | Private Link、Firewall、Proxy、DNS を確認 |
Visual Studio Code の AKS 拡張機能は、AKS クラスターの表示・管理、kubeconfig のマージや保存、AKS Diagnostics、AKS Periscope、Azure Service Operator のインストール、クラスターの開始・停止など、複数の管理機能を提供します。ACR Attach はその中でも、開発環境から AKS と ACR の接続準備を進めるための実用的な導線として位置付けられます。(Microsoft Learn)
Attach 後に必ず確認したい検証ポイント
Attach が成功したように見えても、実際に Pod がイメージを pull できるとは限りません。特に、ABAC、Private Link、Firewall、HTTP Proxy、古いサービスプリンシパル、ノード OS とイメージアーキテクチャの不一致がある環境では、Attach 後の検証が重要です。
まず、ACR が AKS クラスターからアクセス可能かを az aks check-acr で確認します。Microsoft Learn のトラブルシューティング手順でも、ACR の健全性確認と AKS からの到達性確認が初期対応として示されています。(Microsoft Learn)
az aks check-acr \
--resource-group <AKSのリソースグループ> \
--name <AKSクラスター名> \
--acr <ACR名>.azurecr.io次に、テスト用の Deployment を作成し、ACR 上のイメージを指定して Pod が正常に起動するか確認します。もし Pod の状態が ImagePullBackOff や ErrImagePull になった場合は、kubectl describe pod で Events を確認します。Microsoft Learn では、イメージ pull エラー時に kubectl describe pod <podname> -n <namespace> で詳細を確認する手順が示されています。(Microsoft Learn)
kubectl describe pod <pod名> -n <namespace>ロール割り当てを確認する場合は、ACR のスコープでロールが付いているかを見ます。トラブルシューティング手順では、Azure portal の ACR > Access control（IAM）> Role assignments、または az role assignment list で確認する方法が案内されています。(Microsoft Learn)
az role assignment list \
--scope /subscriptions/<subscriptionID>/resourceGroups/<resourceGroupName>/providers/Microsoft.ContainerRegistry/registries/<acrName> \
-o table失敗しやすいポイントと対処法
ACR Attach で失敗する原因は、Visual Studio Code の操作ミスよりも、Azure 側の ID・権限・ネットワーク設定にあることが多いです。よくある失敗を事前に把握しておくと、開発者と管理者の切り分けがしやすくなります。
| 症状 | 主な原因 | 対処 |
|---|---|---|
| Attach は成功したが Pod が起動しない | ACR への pull 権限が不足 | kubelet ID に正しいロールがあるか確認 |
401 Unauthorized が出る | 認可設定、ID、イメージ名の誤り | ロール割り当て、サービスプリンシパル、イメージ名を確認 |
403 Forbidden が出る | ACR のネットワーク制限や Private DNS 設定 | Private DNS、Firewall、許可 IP を確認 |
i/o timeout が出る | Private Link や VNet 間接続の問題 | VNet Peering、DNS、Firewall ルールを確認 |
| ABAC 環境で pull できない | AcrPull 前提で設定している | Container Registry Repository Reader を手動付与 |
| IaC と実環境に差分が出る | VS Code で手動 Attach した | Terraform/Bicep/ARM にロール割り当てを反映 |
特に ABAC 有効な ACR は注意が必要です。通常の AcrPull ではなく、リポジトリ単位の権限モデルに合わせたロール割り当てが必要になるため、従来の「Attach すれば完了」という運用では不十分な場合があります。(Microsoft Learn)
移行期限や設定変更はあるのか
今回確認できる公式情報からは、この Visual Studio Code AKS 拡張機能による ACR Attach に関して、特定日までの移行期限や破壊的変更は確認できません。2026年7月3日相当の更新は、該当ドキュメントに ms.subservice: aks-developer を追加するメタデータ更新であり、本文手順は変更されていないと明記されています。(GitHub)
ただし、次のような環境変更を行った場合は、ACR 連携を再確認する必要があります。
- AKS の kubelet managed identity を変更した
- AKS クラスターをサービスプリンシパルから managed identity に移行した
- ACR の権限方式を ABAC 対応に変更した
- ACR を Private Link 化した
- サブスクリプションやリソースグループを整理した
- Terraform など IaC 管理に移行した
- 本番・検証環境で ACR を分離した
AKS で kubelet managed identity を更新した場合、ACR から pull するために az aks update --attach-acr を再実行して、新しい kubelet に ACR pull 権限を付与する必要があるケースがあります。Microsoft Learn でも、--attach-acr を使っていたクラスターで kubelet managed identity が新しくなる場合、更新後に az aks update --attach-acr を実行する必要があると説明されています。(Microsoft Learn)
グローバル運用での管理者チェックリスト
複数リージョン・複数サブスクリプションで AKS と ACR を運用している場合、Visual Studio Code からの Attach は便利な一方で、ガバナンス上の確認が重要です。特に、開発者がローカルの VS Code から本番リソースを操作できる状態になっている場合、Attach 先を誤ると意図しない AKS クラスターに ACR pull 権限を付与する可能性があります。
| チェック項目 | 確認内容 |
|---|---|
| 命名規則 | ACR と AKS の環境名、国、リージョン、用途が名前で判別できるか |
| 権限設計 | 開発者に Owner 相当の権限を常時付与していないか |
| スコープ | AcrPull を必要以上に広いスコープで付与していないか |
| ABAC | ACR の権限方式が従来 RBAC か ABAC か |
| 監査 | ロール割り当ての変更が Activity Log や監査ログで追えるか |
| IaC 管理 | 手動 Attach の結果が Terraform/Bicep に反映されているか |
| 検証 | az aks check-acr とテスト Pod で確認しているか |
| 障害対応 | ImagePullBackOff 時の切り分け手順があるか |
管理者としては、Visual Studio Code から Attach すること自体を禁止するよりも、どの環境で許可するかを分ける方が現実的です。たとえば、開発環境では開発者に Attach を許可し、本番環境では Pull 権限を IaC または承認付きの運用手順で付与する、といった分離が有効です。
実務でおすすめの運用パターン
小規模な検証環境では、Visual Studio Code の AKS 拡張機能から Attach するだけでも十分です。開発者が AKS と ACR の関係をすばやく作れるため、コンテナーアプリの検証を進めやすくなります。
一方で、本番環境や複数チームで使う共通基盤では、Attach 操作を「一度きりの GUI 設定」で終わらせないことが重要です。最終的には、ACR スコープのロール割り当て、対象 kubelet ID、ABAC の有無、Private Link や Firewall の設定を構成管理に含めるべきです。
| 利用シーン | 推奨パターン |
|---|---|
| 個人検証 | VS Code から Attach して動作確認 |
| チーム開発 | VS Code Attach 後、ロール割り当てをドキュメント化 |
| 本番環境 | Terraform/Bicep で ACR pull 権限を管理 |
| ABAC 有効 ACR | 手動または IaC で Repository Reader 系ロールを設計 |
| 高セキュリティ環境 | Private Link、DNS、Firewall、監査ログまで含めて設計 |
特に CI/CD パイプラインを使う環境では、開発者の VS Code で Attach した結果と、パイプラインが参照する IaC の定義がずれると、再構築時に権限が消えることがあります。Attach 後に本番へ反映する場合は、必ず IaC へロール割り当てを取り込む運用にしておくと安全です。
まず何を確認すべきか
Visual Studio Code の AKS 拡張機能で ACR を AKS に Attach する機能は、AKS が ACR からコンテナーイメージを取得するための重要な接続手順です。2026年7月3日相当の公式更新では本文手順の変更は確認できず、実務上の焦点は「新機能対応」ではなく「ACR pull 権限を正しく設計・検証できているか」にあります。(GitHub)
まずは、対象の AKS クラスターと ACR が正しいか、kubelet ID に適切なロールが付いているか、ABAC 有効 ACR ではないかを確認してください。そのうえで、az aks check-acr とテスト Pod による pull 検証を行えば、GUI 上の成功表示だけに頼らない安全な運用にできます。
コメント