6.1K Views
July 04, 23
スライド概要
Kubernetes Novice Tokyo #26 でのLT資料です
Azure AD ワークロードIDを使って k8sからAzureリソースに 安全にアクセスしよう 2023/07/04 Kubernetes N ovice Tok yo # 26 Shunsuk e Yoshik a wa
自己紹介 Shunsuke Yoshikawa Twitter: https://twitter.com/ussvgr Qiita: https://qiita.com/ussvgr ⚫ 所属: 株式会社エーピーコミュニケーションズ ⚫ 普段の仕事: Azure×コンテナ中心のインフラ構築(AKSとかContainer Appsとか) ⚫ MICUG クラウドネイティブ/内製開発分科会オーガナイザー ⚫ Platform Engineering Meetup 運営メンバー ⚫ Microsoft MVP (Microsoft Azure) 2023/06~ ⚫ 愛知県在住
はじめに: Azureの認証について
Azure ADのアカウントには3つの種類がある ⚫ ユーザーアカウント ユーザーに紐づくアカウント。人が行う操作に利用する。 ⚫ サービスプリンシパル アプリケーション用のアカウント。ID/PW or 証明書を用いて認証する。 ⚫ マネージドID VMなどの Azureリソース に紐づくアカウント。 Azureのプラットフォーム内で認証するため、ID/PWの管理が不要。
アプリケーションからAzure ADの認証をする 対応している環境であれば マネージドID を使うのが推奨。 マネージドID が使えない場合のみ サービスプリンシパル を用いる。 ※ マネージドID が使えない例: ⚫ オンプレミスや他クラウド上のアプリケーション ⚫ マネージドIDに対応していないAzureサービス
マネージドID の種類 Azureリソースとの紐づけ方によって、以下の2種類が存在する。 ⚫ システム割り当てマネージドID リソースとマネージドIDが1対1で紐づく ⚫ ユーザー割り当てマネージドID リソースとマネージドIDが多対多で紐づく
AKS(Azure Kubernetes Service) における マネージドID デフォルトの設定でAKSクラスターを作ると、 コントロールプレーンに紐づくマネージドID と ノードプールに紐づくマネージドID の2種類が作られる。 ⚫ コントロールプレーンのマネージドID (システム割り当て) ノードの増減やIPアドレスの割り当てなど、 Kubernetesクラスターの動作に必要な操作を行うためのID。 ⚫ ワーカーノードのマネージドID (ユーザー割り当て) ワーカーノードやPodから他のAzureリソースにアクセスするためのID。 用途に応じ複数のマネージドIDを同時に割り当てることもできる。
マネージドID の利用例 ワーカーノードの マネージドIDを使って Azure ADに認証 AKSワーカーノードの マネージドIDからの Image Pullを許可
Azure AD ワークロードIDの利用シーン
こんなときどうする? Namespace AのPodに対しAzureリソースへのアクセスを許可する。 Namespace BのPodにはAzureリソースへのアクセスを許可しない。 Namespace A Namespace B
Azure AD ワークロードID の利用 従来のマネージドIDでは、AKSクラスター上のすべてのPodに対し 画一的な権限を渡すことになってしまい、 マルチテナントな利用方法には不向きであった。 より細かい単位で権限の割り当てを行うための機構として、 OpenID Connectを利用する Azure AD ワークロードID が誕生した。 2023/04にGA!
認証の仕組み 引用元: Concepts – Azure AD Workload Identity (https://azure.github.io/azure-workload-identity/docs/concepts.html)
Azure AD ワークロードIDの利用方法
手順1
AKSクラスターを作成する際、
--enable-oidc-issuer オプション付きで作成する。
$ az aks create -g $RG_NAME -n $AKS_NAME --enable-oidc-issuer
出力結果にある issuerUrl の値を控えておく。
"oidcIssuerProfile": {
"enabled": true,
"issuerUrl": "https://japaneast.oic.prod-aks.azure.com/hoge/fuga/"
},
手順2 ユーザー割り当てマネージドIDを作成する $ az identity create -n $MANAGEDID_NAME -g $RG_NAME 出力結果にある clientId の値を控えておく。 "clientId": "abcdefgh-1234-5678-9abc-0123456789ab", 作成したマネージドIDに、必要なIAMロールを割り当てておく。
手順3 AKSクラスター上にサービスアカウントを作成する。 その際、annotationsに手順2で作成したマネージドIDのclientIdを指定する。 azure.workload.identity/use: "true" のラベルも必須。 apiVersion: v1 kind: ServiceAccount metadata: annotations: azure.workload.identity/client-id: <マネージドIDのclientId> labels: azure.workload.identity/use: "true" name: <サービスアカウント> namespace: <Namespace>
手順4
マネージドIDにフェデレーション資格情報の登録を行う。
手順1で確認した issuerUrl と
手順3で作成した サービスアカウントの情報を利用する。
az identity federated-credential create --name myfederatedIdentity \
--identity-name "${MANAGEDID_NAME}" --resource-group "${RG_NAME}" \
--issuer "<issuerUrl>" \
--subject system:serviceaccount:"<Namespace>":"<サービスアカウント>"
手順5 アプリケーションのPodを起動する際、 手順3で作成したサービスアカウントを指定する apiVersion: v1 kind: Pod metadata: name: test-pod namespace: <Namespace名> spec: serviceAccountName: <サービスアカウント> containers: - name: hoge image: hogehoge:latest
アプリケーションからの認証 アプリケーションからは ⚫ Azure Identity SDK ⚫ Microsoft Authentication Library (MSAL) のどちらかを使って認証を行う。 PythonでAzure Identity SDKを使う場合は以下のように認証を行う。 from azure.identity import DefaultAzureCredential credential = DefaultAzureCredential()
まとめのイメージ図① OIDC Provider ②Issue URLにアクセスし要求を検証 ①SAのTokenを送り AADのTokenを要求 Namespace A ③マネージドIDのTokenを返す ④マネージドIDを利用してAzureリソースにアクセス Namespace B
まとめのイメージ図② OIDC Provider Namespace A マネージドIDに設定した フェデレーション情報と不一致の場合は 認証に失敗する Namespace B
まとめ ⚫ Azureリソースの認証には極力マネージドIDを使おう ⚫ でもAKSのマルチテナント利用を考えると、 クラスタ全体が同じ権限なのは困る ⚫ だから Azure AD ワークロードID を使おう
おまけ情報 過去に弊社ブログにも書いたのでこちらも見てね https://techblog.ap-com.co.jp/entry/2022/12/02/113000
おまけ情報2 Azure AD ワークロードIDは、 KubernetesクラスターがOIDCのIssuerに対応していればよいので、 実は AKS以外でも動く(らしい) EKS・GKEからAzureリソースにアクセスしたい場合にも 同様の手順で設定できると思う(未検証) 誰か試してみて(他力本願) 参考: Managed Clusters – Azure AD Workload Identity (https://azure.github.io/azure-workload-identity/docs /installation/managed-clusters.html)
Enjoy Kubernetes with Azure !