MS_AKSResourceAccess - NetDevInfraWGinOSSConsortium/NetDevInfraWiki GitHub Wiki

AKSユーザ・アプリからのリソース・アクセス

概要

補足（何の話か）: AKS Master APIにAzAD認証を統合する。 が
「人が Master API を操作するときの認証」の話であるのに対し、
本ページは「**アプリ（Pod）**が Azure SQL Database や
ストレージ にアクセスするときの資格情報」の話である。

【人 → Master API】  … MS_AKSMasterAPIAzAD
【Pod → Azure リソース】… 本ページ

詳細

Secret 管理

  • ≒ ユーザ/パスワード（Secret）の方式。
  • AKS 側ではなく、K8s 側の機能

環境変数

  • Deployment.yaml ファイルの環境変数に Secret を直接入れる。
  • アプリから、環境変数取得 API から Secret を取得する。

※ Deployment.yaml ファイルに平文で Secret を書く必要がある。

補足: この方式は YAML が Git に入るのが最大の問題で、
リポジトリの履歴に平文の資格情報が残る。
検証以外で採用してはならない。

Secret 機能

Kubernetes Secret と言う K8s の機能。

  • Secret.yaml ファイルを使用して制御プレーンに暗号化して保存。
  • Deployment.yaml ファイルの環境変数に Secret 機能の参照を入れる。
  • アプリから、環境変数取得 API から Secret を取得する。

※ 管理者権限がアレば kubectl で取り出せてしまうという問題がある。

kubectl get secret <Secret名> -o json

移行メモ（「暗号化して保存」について）: Kubernetes Secret は
既定では Base64 エンコードされているだけで、暗号化ではない。
原文が「暗号化して保存」としているのは、
AKS では etcd が保存時に暗号化されている（Microsoft 管理キー）ことを
指すものと解される。
いずれにせよ、原文が指摘するとおり
kubectl get secret で平文が取り出せるため、
「Secret に入れたから安全」ではない。

対策としては、

  • K8s RBAC で secrets の get 権限を絞る、
  • 顧客管理キー（CMK）による etcd 暗号化を構成する、
  • そもそも Secret に置かず、後述の Key Vault 連携にする、

といったものがある。

Managed ID

  • Windows 認証的な。
  • K8s 側ではなく、AKS 側の機能。
    • なので、Azure 系のリソースのみが対象
    • K8s 側にプラグインのインストールが必要になる。

補足（「Windows 認証的な」という喩え）: この喩えは的確である。
接続文字列にパスワードを書かず、実行主体の ID で認証するという点で、
オンプレミスの Windows 統合認証と同じ発想になる。

【Secret 方式】  接続文字列 = "...;User Id=xxx;Password=yyy"  ← 秘密を持つ
【Managed ID】   接続文字列 = "...;Authentication=Active Directory Default"
                 ↑ 秘密を持たない。ID そのもので認証する

秘密を持たない＝漏洩・失効・ローテーションの問題が構造的に消える、
というのが本質的な利点である。

Pod ID 機能

  • Managed ID ≒ Pod ID 機能で、

  • Pod ID 機能を有効にすると Pod で Managed ID が利用可能。

  • ただし、ヤリ過ぎ感が出てくる。

補足（最新化 / 重要）: 本文の AAD Pod Identity は非推奨であり、
現在は Microsoft Entra Workload ID（旧 Azure AD Workload Identity）に
置き換わっている。

AAD Pod Identity（旧） Workload ID（現行）
仕組み ノード上の NMI Pod が IMDS への通信を横取りする K8s のサービス アカウント トークンを Azure AD が信頼（OIDC フェデレーション）
前提 専用の DaemonSet / CRD が必要 クラスタの OIDC 発行者を有効化するだけ
対象 Linux ノードのみ Linux / Windows
課題 起動時の競合、スケール時の遅延 解消

原文の「ヤリ過ぎ感」は、
通信を横取りする仕組みの複雑さに対する率直な感想と読める。
Workload ID はこの仕組みを排し、
標準的な OIDC フェデレーションに置き換えたものなので、
現在ではこの懸念はかなり薄れている。

【Workload ID の流れ】
  Pod ──サービス アカウント トークン──▶ Azure AD
                                         │ OIDC 発行者を信頼
                                         ▼
                                   アクセス トークン
                                         │
                                         ▼
                             Azure SQL / Storage / Key Vault

Key Vault & FlexVol

  • Key Vault

    • Key Vault には、Pod ID 機能でアクセス可能。
    • 他にも、SPN を使用した方式があるらしい。
    • ココから取得した Secret を、接続文字列等に組込む。
    • ただし、AKS のプラットフォーム依存コードになる。

  • FlexVol

    • K8s でボリュームのプラグインを書けるようにしたもの
    • Key Vault FlexVolume プラグインと言うものがある。
      • Key Vault の情報を一時ドライブに復元する。
      • プラットフォーム依存コードを「削減」できる。
        ・しかし、ヤリ過ぎ感が出てくる。
        ・そして（、結局）、環境変数ではない。

補足（最新化）: FlexVolume は非推奨（K8s 1.26 で削除）であり、
後継の CSI (Container Storage Interface) に移行している。
AKS では Azure Key Vault Provider for Secrets Store CSI Driver が
マネージド アドオンとして提供されている
（az aks enable-addons --addons azure-keyvault-secrets-provider）。

原文の「結局、環境変数ではない」という不満に対しては、
現在の CSI ドライバーが **Kubernetes Secret への同期（secretObjects）**を
サポートしており、

Key Vault ──CSI──▶ ボリューム（ファイル）
                    └──同期──▶ K8s Secret ──▶ 環境変数

という形で環境変数として受け取れるようになっている。
ただし K8s Secret を経由する分、前述の
「kubectl get secret で見える」問題は残るため、
ファイルとして読む方が安全である。

現在の選択の目安

要件 推奨
Azure リソース（SQL / Storage / Key Vault）へのアクセス Workload ID（秘密を持たない。最優先）
外部サービスの API キー等、秘密を持たざるを得ない Key Vault ＋ Secrets Store CSI Driver
検証・一時的 Kubernetes Secret
いずれの場合も YAML に平文で書かない

参考

Key Vault

Microsoft Learn

Qiita

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

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

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