MS_AKSClusterPermissions - NetDevInfraWGinOSSConsortium/NetDevInfraWiki GitHub Wiki

AKSクラスタ作成・操作に必要な権限

概要

複雑なモノなので、それなりに複雑。

補足（なぜ複雑になるのか）: AKS の権限が分かりにくいのは、
登場する ID が 3 種類あり、それぞれ役割が違うためである。

ID 誰が使うか 何のために
作業者の ID 人（az aks create を打つ人） クラスタを作る
制御プレーン用 ID AKS 自身 VNET / LB / ディスクなど Azure リソースを操作する
ノード（kubelet）用 ID 実行ノード ACR からイメージを Pull する

本ページはこの 3 つを順に説明している。
「誰の権限の話をしているか」を意識して読むと整理しやすい。

詳細

AKS（制御プレーン）用 ID

AKS クラスタに必要な権限

  • AKS クラスタ作成には az aks create を実行する。

    • az aks create の実行には高権限が必要

    • az aks create では以下の操作・権限が必要になる。

  • AKS クラスタへのデプロイでは kubectl apply を実行する。

    • kubectl apply の実行にはコンテナ・レジストリのアクセス権限が必要

サブスクリプションの Contributor ロール

「制御プレーン、実行ノードを作成する。」
ために必要になる。

Azure Active Directory のアプリ ID 作成権限

「AKS(制御プレーン)用 ID を
Azure Active Directory に登録する。」ために必要になる。

サブスクリプションの Security Admin ロール

「AKS(制御プレーン)用 ID に高い権限を持たせる。」
ために必要になる。

ACR にアクセスする AcrPull ロール

「kubectl apply の実行のためコンテナ・レジストリを pull する。」
ために必要になる。

移行メモ（誰が Pull するのか）: この項の記述は
「kubectl apply の実行に ACR の権限が必要」と読めるが、
正確には **イメージを Pull するのはノード（kubelet）**であり、
kubectl apply を実行する人の権限ではない。

作業者 ──kubectl apply──▶ Master API（マニフェストを登録するだけ）
                             │
                             ▼
                         ノード（kubelet）──AcrPull──▶ ACR

したがって AcrPull ロールを付与する相手は
ノード（kubelet）の ID である。後述の
「作成する AppID」で <clustername>-agentpool に
AcrPull を付与しているのは、この理由による。

AKS(制御プレーン)用 ID の作成方式

以下の方法で、az aks create を行い、
AKS(制御プレーン)用 ID を作成する。

SPN 方式

AzAD のアプリ ID 作成権限を持って「いない」ケース

Managed ID 方式（Azure Managed ID）

Owner ロール ＋ AzAD のアプリ ID 作成権限を持ってい「る」ケース

補足（最新化 / どちらを選ぶか）: 現在、
az aks create の既定はマネージド ID 方式であり、
SPN 方式は非推奨である。新規構築では選ぶ理由がない。

SPN 方式 マネージド ID 方式（推奨）
シークレット あり（既定 1 年で失効） なし
失効時の影響 クラスタが Azure リソースを操作できなくなる（LB 更新失敗など） 発生しない
更新作業 az aks update-credentials が必要 不要
事故 「1 年後に突然壊れる」が典型 －

原文が「扱いが容易」と述べるとおりだが、実際には
「シークレットが失効して 1 年後に壊れる」事故を構造的に消せる
ことが最大の利点である。
既存クラスタは az aks update --enable-managed-identity で移行できる。

付与する権限と作成する AppID の対応

付与する権限

以下の権限が必要になる。

作成する AppID

補足（--attach-acr で済む）: AcrPull の付与は、手作業で
ロール割り当てを作らなくても、次のコマンドで自動化できる。

# クラスタ作成時
az aks create ... --attach-acr <ACR名>

# 既存クラスタに後付け
az aks update -n <クラスタ名> -g <RG名> --attach-acr <ACR名>

これは内部で kubelet の ID に AcrPull ロールを割り当てる処理を行う
（＝上記の <clustername>-agentpool への付与に相当）。
ただし実行者にロール割り当てを作る権限（Owner または
User Access Administrator）が必要な点に注意。

AKS 管理リソースグループ外を利用する場合

対象のリソースに対する
サブスクリプションの Contributor ロール権限を付与する。

予め作成した VNET 上に AKS クラスタを作成

既存の VNET に対する
サブスクリプションの Contributor ロール権限を付与する。

補足（なぜ「管理リソースグループ外」が問題になるか）: AKS は
クラスタ本体とは別に、MC_<RG名>_<クラスタ名>_<リージョン> という
管理用リソース グループを自動生成し、
ノード（VMSS）、ディスク、ロードバランサをそこに作る。
この中のリソースは AKS が自由に操作できる。

しかし、既存の VNET のように「外」にあるリソースを使う場合、
AKS の ID には自動では権限が付かない。
したがって、

  • 既存 VNET のサブネット → Network Contributor を明示的に付与、
  • 既存の Public IP / LB → 同様に権限を付与、

という作業が必要になる。
閉域構成（AKSのアウトバウンドをAzure Firewallで制限する。）では
既存 VNET を使うのが前提なので、必ず遭遇する。

なお、原文は「Contributor ロール」としているが、
最小権限としては VNET に対する Network Contributor で足りる。

...

  • 基本的に、上記と同じ。
  • AcrPull ＋ Managed IDのような場合は、
    専用コマンドが用意されているケースはありそう。

補足: 原文の推測どおり、前述の --attach-acr がそれにあたる。

参考

Tags: 移行, クラウド, コンテナ, Azure, AKS, IaC, セキュリティ

このWikiは「Open棟梁Project」,「OSSコンソーシアム 開発基盤部会」によって運営されています。

⚠️ **GitHub.com Fallback** ⚠️