MS_AKSMasterAPIAzAD - NetDevInfraWGinOSSConsortium/NetDevInfraWiki GitHub Wiki

AKS Master APIにAzAD認証を統合する。

概要

AKS Master API の認証に、

補足（何が変わるのか）: 既定の AKS では、
az aks get-credentials で取得した kube config（証明書）だけで
Master API を操作できてしまう。
これはファイルなので、コピーすれば誰でも同じ権限で操作できる。

【既定】
  kube config（証明書）── そのまま操作可能。持ち出されたら終わり

【Azure AD 統合】
  kube config（設定のみ）─▶ ブラウザで Azure AD 認証
                             ├ MFA
                             ├ 条件付きアクセス
                             └ トークン（有効期限あり）

つまり kube config の持ち出しが即座に権限にならなくなるのが最大の効果。
原文が「持ち出し対策」と位置づけているのは、この意味である。

詳細

作成手順

  • Azure リソース グループを作成
az group create --name myResourceGroup --location centralus
  • 次に、AKS クラスターを作成
az aks create -g MyResourceGroup -n MyManagedCluster --enable-aad

補足（最新化）: 現在の AKS では Azure AD 統合（AAD v2）が既定であり、
--enable-aad を明示しなくても有効になる。
さらに、次の 2 つを併用するのが現在の推奨構成である。

オプション 効果
--enable-azure-rbac K8s 内部の認可も Azure RBAC で行う（後述）
--disable-local-accounts --admin によるローカル証明書の取得を禁止する

特に --disable-local-accounts は重要で、これを付けないと
az aks get-credentials --admin で Azure AD を迂回できてしまい、
本ページの対策が骨抜きになる。

認証方法

補足（原文の推測について）: kubectl から Azure AD 認証を行う
kubelogin は、いくつかの認証モードを持つ。

モード 方式
devicecode（従来の既定） デバイス コード フロー（コードを表示し、別ブラウザで入力）
azurecli Azure CLI が取得済みのトークンを流用
interactive（webbrowser） Loopback Interface Redirection（原文の推測どおり）
workloadidentity / msi / spn 非対話（CI/CD 用）

したがって原文の推測は
interactive モードについては正しい。
ただし当時の既定はデバイス コード フローだった。
なお、条件付きアクセスを効かせたい場合、
デバイス条件（準拠デバイス等）を評価できるのは対話モードなので、
interactive を選ぶ必要がある。

トレードオフ

補足（「事足りることも多い」への留保）: 原文の
「プライベート化で事足りる」という判断は、
「VNET に入れる人＝信頼できる人」という前提に立っている。
FgCF の用語で言えば、境界型の発想である。

ゼロトラストの観点では、両者は守るものが違う。

プライベート化 / IP 制限 Azure AD 統合
守るもの どこから来たか 誰が来たか
kube config 持ち出し 防げない（VNET 内なら使える） 防げる（追加認証が要る）
内部犯行・権限逸脱 防げない 監査ログに ID が残る
MFA / 条件付きアクセス 適用不可 適用可

特に監査要件がある場合、「誰が kubectl で何をしたか」を
ID 単位で追跡できるのは Azure AD 統合だけである。
現在は既定で有効なので、あえて外す理由は薄い。

2 段階の認可（AAD 統合 ＋ Azure RBAC）

Azure AD 統合だけでは**認証（誰か）**が Azure AD になるだけで、
**認可（何ができるか）**は K8s 側の RoleBinding で管理する。
--enable-azure-rbac を付けると、認可も Azure RBAC に寄せられる。

【AAD 統合のみ】
  認証: Azure AD  →  認可: K8s RBAC（ClusterRoleBinding で AAD グループを紐付け）

【AAD 統合 + Azure RBAC】
  認証: Azure AD  →  認可: Azure RBAC（「Azure Kubernetes Service RBAC 閲覧者」等）

後者は PIM による JIT 昇格と組み合わせられるため、
エンタープライズでは扱いやすい。

参考

Microsoft Learn

Tags: 移行, クラウド, Azure, Active Directory, AKS, IaC, セキュリティ, 通信技術, 認証基盤

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

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