Entra IDによるAzure Kubernetes Serviceの認証認可強化

Entra IDによる Azure Kubernetes Serviceの 認証認可強化

Agenda  自己紹介  Kubernetesの概要とAzure Kubernetes Service(AKS)  Entra IDによるAKSの認証認可強化   Intuneのデバイスコンプライアンス状態に基づく(条件付きアクセス) AKSのアクセス制御 グループ単位のPIMを利用したKubernetes管理者ロールのJITアクセス

自己紹介  ハンドルネーム：風の時代のエンジニニャ  経歴 新卒では介護職をしており、 その後インフラエンジニア→セキュリティエンジニアへ転職。 現在、主にコンテナセキュリティやクラウドセキュリティのR&D業務に従事  趣味 タロット(ほぼ毎日占っています)  SNS/Githubアカウント • X ：@windagecat • Github：https://github.com/windagecat

• https://github.com/windagecat

このセクションのゴール 以下3つをざっくりと理解する  Azure Kubernetes Service(AKS)とは何か  Entra IDおよびAzure RBAC統合によるAKS の認証認可の仕組み  AKSの認証認可強化に使用できるEntra ID プレミアムライセンスの主な機能

Kubernetesの概要と Azure Kubernetes Service(AKS)

Kubernetesとは？ ざっくりいうと、VMや物理サーバで構成されたクラスタ上 に、1つ以上のdocker等のコンテナが内包されたPodが立って いるプラットフォーム Pod Kubernetesクラスタ VMや物理サーバで構成 KubernetesはPodの デプロイ やスケーリング、およびその他関連 するリソースの管理を行う

Azure Kubernetes Service(AKS)とは？  AKSとは？ Azureで提供されているKubernetesのPaaSサービス。  AKSを使用するメリット  構築が困難とされるKubernetesクラスタをコマンド1つで たてられる。  IaaSより、管理コストが楽  クラスタを構成しているAzure VMのOS部分の管理不要  Kubernetes API Server※1の管理不要  Entra IDによるAKSの認証認可強化ができる ※1 API Serverとは、 Podやその他関連するリソースを管 理するための中核を担うkubernetesのコンポーネント

Entra IDによる AKSの認証認可強化

Entra IDおよびAzure RBAC統合による AKSの認証認可 Entra ID認証統合およびAzure RBACの認可統合により、AKSの認証認可の一元管理ができる Entra ID認証統合およびAzure RBACの認 可統合による、AKSへのアクセスの仕 組み ③トークン検証(認証) Entra ID AKS Pod ②Webhookによりアクセストークン検証(認証) ①kubectlコマンドの実行 ⑤認証に成功しかつ権限が適切に付与され Kubernetes ていれば、AKS上のPod等のリソース操作が API Server 可能 開発者 or 運用者 ④権限ロール確認(認可) Azure RBAC Entra ID プレミアムライセンスの機能を使用すると、さらに認証認可を強化で きる

AKS認証認可強化に使用できる プレミアムライセンス機能 プレミアムライセン ス機能 概要 条件付きアクセス Privileged Identity Management(PIM) AKS認証認可強化でできること 利用ケース 機能 ユーザーやデバイス IDを基にAzureや office365系のリソー スアクセスを制御す る (Entra IDと認証統合 された)AKSに対する アクセスを限定する ・Intuneのデバイス コンプライアンス状 態に基づくアクセス 制御 ・送信元IPに基づく 制御 常時割り当てが危険 なEntra IDやAzureの 管理者ロールを一時 的に付与できる(JIT アクセス)。 割り当てやロール無 効の日時など、監査 ログに記録される。 通常時は割り当てな グループ単位のPIM を利用した管理者 いが、Kubernetes管 理者ロールが緊急に ロールのJITアクセス 必要な場合、 承認さ れた期間のみその ロールを割り当てる

Intuneのデバイスコンプライアンス 状態に基づく(条件付きアクセス) AKSのアクセス制御

Intuneのデバイスコンプライアンス状態に基づく AKSのアクセス制御の流れ1 Intuneによる管理下かつコンプライアンスポリシーに準拠し ている端末からのアクセス 1. 端末からKubernetes API Serverへkubectlコマンドの実行 2. WebhookによりEntra ID へトークン検証をリクエスト 3. トークン検証と並行して、デバイス準拠状態の条件付きアクセスポリシーを検証 4. アクセス元の端末がIntuneによる管理下でコンプライアンスポリシーに準拠している場合、AKS へのアクセスが許可される。 条件付き アクセス 開発者 or 運用者 Entra ID ③トークン検証と並行して、デバイス準拠状 態の条件付きアクセスポリシーを検証 ②Webhookによりトークン検証 ①kubectlコマンドの実行 Intuneによる管理下かつ コンプライアンスポリシーに準拠 の端末 Kubernetes API Server ④準拠の場合、アクセスが許可 AKS

Intuneのデバイスコンプライアンス状態に基づく AKSのアクセス制御の流れ2 Intuneによる管理下かつコンプライアンスポリシーに準拠し ている端末からのアクセス 1. 端末からKubernetes API Serverへkubectlコマンドの実行 2. WebhookによりEntra ID へトークン検証をリクエスト 3. トークン検証と並行して、デバイス準拠状態の条件付きアクセスポリシーを検証 4. アクセス元の端末がIntuneの非管理下または管理下でもコンプライアンスポリシーに非準拠の 場合、AKSへのアクセスが拒否される。 条件付き アクセス Entra ID ③トークン検証と並行して、デバイス準拠状 態の条件付きアクセスポリシーを検証 ②Webhookによりトークン検証 ①kubectlコマンドの実行 Intuneに管理されていない or コンプライアンスポリシーに非準拠の端末 Kubernetes API Server ④非準拠として、アクセスを拒否 AKS

条件付きアクセスの注意点 • Entra IDへログイン後、アクセストークンの有効期限は60 分から 90 分のため、この 間デバイス準拠から非準拠に変わってもトークンの有効期限まで、AKSへアクセス できる。 →Intune管理下のデバイスがマルウェア感染したときに、非準拠になるよう構成して いる(Defender for EndpointとIntuneの統合など)場合、次の条件付きアクセスポリシーの チェックまでの間に感染拡大する可能性があるため、感染が発覚したすぐに端末自体 のネットワーク隔離を行うこと。  隔離の例として、Defender for Endpointのカスタム検出ルールを使用して、アラー トが生じた端末の自動隔離を行う

サンプルの条件付きアクセスポリシー Github(Azure-container-env_Auth-and-Autho-Enhancement/conditinalaccess_PIM/条件付きアクセスポリシーのサン プル.md at main · windagecat/Azure-container-env_Auth-and-Autho-Enhancement (github.com))に条件付きアクセスポ リシーのサンプル(自分なりの推奨ポリシー)を公開しています。 ご興味のある方は、ご覧ください。 サンプルポリシーの概要は、下表に示します。 サンプルの条件付きアクセスポリシーの概要 ポリシー名 概要 備考 コンテナ環境のデバイ ス準拠ポリシー AKS、ACR、Azure Devops Serviceのコンテナ 環境向けのデバイスベースのアクセス制御 ポリシー ・kubeletのACRに対する認証に 失敗するため、ACRへのアクセ ス制御は設定していない ・8時間ごとにサインインしなお すように、構成 危険なサインインポリ シー 不正ログイン攻撃などの危険なサインイン に対するリスクベースポリシー 危険なユーザーリスク ポリシー パスワード漏洩などのユーザーそのものの リスクに対するリスクベースポリシー MFA必須ポリシー MFAの登録と認証を強制するポリシー Intuneポリシー Intuneの登録や参加またはデバイスからの 再同期の際、毎回MFAによるサインインを 強制するポリシー

グループ単位のPIMを利用し たKubernetes管理者ロールの JITアクセス

Kubernetes管理者ロールに対するJITアクセスの流れ 1. 2. 3. 4. 開発者or運用者から、一定期間(2~3時間など)の管理者ロールが事前に付与されているグループ へのメンバーシップの有効化(アクティブ化)を申請 承認者によるアクティブ化を承認 承認後、開発者or運用者は承認された期間のみグループへのメンバーシップが有効化され、管 理者ロールでのAKSへのアクセスが可能 承認された期間を過ぎると、非アクティブ化され(メンバーシップから自動的に外れる)、管理 者ロールでのAKSへのアクセスが不可になる PIM ①一定期間(2~3時間など)のグループ へのメンバーシップの有効化(アク ティブ化)を申請 開発者 or 運用者 Entra ID グループ 管理者ロールが事 前に付与されてい ③承認後、承認された期間のみグループへのメンバーシップが有効化され、管理者ロールでの る AKSへのアクセスが可能。 AKS ④承認された期間を過ぎると、非ア クティブ化され、管理者ロールでの AKSへのアクセスが不可になる ②アクティブ化を承認 承認者

JITアクセスのハンズオン Github(Azure-container-env_Auth-and-Autho-Enhancement/conditinalaccess_PIM/PIMによるAKSに対するJITアクセ ス.md at main · windagecat/Azure-container-env_Auth-and-Autho-Enhancement (github.com))にJITアクセスのハンズオ ンを公開しています。 ご興味のある方は、ご覧ください。 ハンズオンに出てくるPIM用のEntra ID グループについて、下表に示します。 PIM用のEntra ID グループ Entra ID グループ名 グループ概要 管理者ロール(Azureロール) 管理者ロール スコープ リソースグループ k8sadmin k8sクラスタ内のすべてのリ ソースに対するフルアクセス ロールが付与されているグ ループ Azure Kubernetes Service RBAC Cluster Admin(ビルドイン) k8scontributor k8sクラスタ内のRBAC以外す べてのリソースに対するフル アクセスロールが付与されて いるグループ Azure Kubernetes Service RBAC Cluster Contributor(カスタム ロール) armadmin すべてのAzureリソースを管理 するためのフルアクセスロー ルが付与されているグループ Owner(ビルドイン) armcontributor RBAC以外すべてのAzureリ ソースを管理するためのフル アクセスロールが付与されて いるグループ Contributor(ビルドイン)

最後に 今回お話ししたAzure Kubernetes Serviceの認証認可強化の詳細につ いて、Github上に公開しています。 https://github.com/windagecat/Azure-container-env_Auth-and-AuthoEnhancement/tree/main →条件付きアクセスポリシーとPIMの他に、Azure RBACを使用し たKubernetesロールの権限昇格の防止についても紹介しています。 ご興味ある方はご覧いただき、ぜひハンズオンも試してみてく ださい！

• https://github.com/windagecat/Azure-container-env_Auth-and-Autho-