この記事では、Amazon Elastic Kubernetes Service (Amazon EKS) と Azure Kubernetes Service (AKS) によって、Kubernetes ワークロードがクラウド プラットフォーム サービスにアクセスするための ID を提供する方法について説明します。 アマゾン ウェブ サービス (AWS) の ID およびアクセス管理 (IAM) と Microsoft Entra ID の詳細な比較については、次を参照してください。
このガイドでは、AKS クラスター、組み込みサービス、アドオンが マネージド ID を使用して、ロード バランサーやマネージド ディスクなどの Azure リソースにアクセスする方法について説明します。 また、この記事では、AKS ワークロードが接続文字列、アクセス キー、またはユーザー資格情報を必要とせずに Azure リソースにアクセスできるように、 Microsoft Entra ワークロード ID を使う方法についても説明します。
Note
この記事は、Amazon EKS に詳しいプロフェッショナルの方が Azure Kubernetes Service (AKS) を理解するのに役立つ一連の記事の一部です。
Amazon EKS の ID とアクセスの管理
Amazon EKS には、Kubernetes ポッド内から AWS サービスを呼び出す 2 つのネイティブ オプションがあります。サービス アカウントの IAM ロールと、Amazon EKS サービスにリンクされたロールです。
サービス アカウントの IAM ロール では、IAM ロールが Kubernetes サービス アカウントに関連付けられます。 このサービス アカウントにより、サービス アカウントを使用するすべてのポッド内のコンテナーに AWS アクセス許可が提供されます。 サービス アカウントの IAM ロールには、次の利点があります。
最小特権: ノード上のポッドが AWS API を呼び出すために、そのノードの IAM ロールに拡張アクセス許可を提供する必要がありません。 IAM アクセス許可の範囲をサービス アカウントに設定できます。これにより、そのサービス アカウントを使用するポッドのみがそれらのアクセス許可にアクセスできます。 また、この機能を使用すると、
kiamやkube2iamなどのサードパーティ ソリューションが不要になります。資格情報の分離: コンテナーは、そのコンテナーが属するサービス アカウントに関連付けられている IAM ロールの資格情報のみを取得できます。 コンテナーは、別のポッドに属する別のコンテナーの資格情報にはアクセスできません。
監査性: Amazon CloudTrail により、遡及的監査を実行できるようにアクセスとイベントのログが提供されます。
Amazon EKS サービスにリンクされたロール は、Amazon EKS に直接リンクされる一意の IAM ロールです。 サービスにリンクされたロールは、Amazon EKS によって事前に定義されており、そのロールの代理で他の AWS サービスを呼び出すために必要なすべてのアクセス許可が含まれます。 Amazon EKS ノードの IAM ロールの場合、Amazon EKS ノード kubelet デーモンがノードの代理で AWS API を呼び出します。 ノードは、IAM インスタンス プロファイルおよび関連するポリシーから、これらの API 呼び出しのアクセス許可を取得します。
AKS クラスターのマネージド ID
AKS クラスターには、ロード バランサーやマネージド ディスクなどの Azure リソースにアクセスするための ID が必要です。 この ID には、マネージド ID またはサービス プリンシパルを指定できます。 既定では、AKS クラスターを作成すると、 システム割り当てマネージド IDが自動的に作成されます。 Azure プラットフォームによって ID が管理されるため、シークレットをプロビジョニングまたはローテーションする必要はありません。 Microsoft Entra のマネージド ID について詳しくは、 「Azure リソースのマネージド ID」を参照してください。
AKS では サービス プリンシパル が自動的に作成されないため、サービス プリンシパルを使用する場合は作成する必要があります。 サービス プリンシパルは最終的に期限切れになるため、クラスターの動作を維持するためにサービス プリンシパルを更新する必要があります。 サービス プリンシパルを管理する場合、複雑さが増すため、マネージド ID を使用した方が簡単です。
マネージド ID は、基本的にサービス プリンシパルのラッパーであり、簡単に管理できます。 アクセス許可の要件は、サービス プリンシパルでもマネージド ID でも同じです。 マネージド ID には、証明書ベースの認証が使用されます。 各マネージド ID の資格情報は有効期限が 90 日で、45 日後にローテーションされます。
AKS では、システム割り当て、およびユーザー割り当てマネージド ID の両方の種類が使用され、これらの ID は不変です。 AKS 仮想ネットワーク、アタッチされた Azure ディスク、静的 IP アドレス、ルート テーブル、またはユーザー割り当て kubelet ID を、 ノード リソース グループ外のリソースと共に作成または使用すると、Azure CLI によってロールの割り当てが自動的に追加されます。
Bicep テンプレート、Azure Resource Manager テンプレート、Terraform モジュールなどの別の方法を使用して AKS クラスターを作成する場合は、クラスター マネージド ID のプリンシパル ID を使用してロールの割り当てを行う必要があります。 AKS クラスター ID には、少なくとも、ご利用の仮想ネットワーク内のサブネットに対する ネットワーク共同作成者 ロールが必要です。 組み込みのネットワーク共同作成者ロールを使用する代わりにカスタム ロールを定義するには、次のアクセス許可が必要です。
Microsoft.Network/virtualNetworks/subnets/join/actionMicrosoft.Network/virtualNetworks/subnets/read
クラスター ID で既存のリソースにアクセスする必要がある場合 (たとえば、AKS クラスターを既存の仮想ネットワークにデプロイする場合)、ユーザー割り当てマネージド ID を使用する必要があります。 システム割り当てコントロール プレーン ID を使用する場合、リソース プロバイダーはクラスターを作成する前にそのプリンシパル ID を取得できないため、クラスターのプロビジョニング前に適切なロールの割り当てを作成することはできません。
マネージド ID の概要
AKS では、組み込みのサービスとアドオンに対して次の ユーザー割り当てマネージド ID が使用されます。
| ID | 名前 | 使用事例 | 既定のアクセス許可 | 独自の ID を使用する |
|---|---|---|---|---|
| コントロール プレーン | AKS クラスター名 | イングレス ロード バランサーと AKS マネージド パブリック IP、クラスター オートスケーラー、Azure Disk と Azure File CSI のドライバーなど、クラスター リソースを管理します | ノード リソース グループの共同作成者ロール | サポートされています |
| kubelet | AKS クラスター名 - agentpool | Azure Container Registry を使用して認証を行います | NA (kubernetes v1.15+ 用) | サポートされています |
| アドオン | HTTPApplicationRouting | 必要なネットワーク リソースを管理します | ノード リソース グループの閲覧者ロール、DNS ゾーンの共同作成者ロール | いいえ |
| アドオン | イングレス アプリケーション ゲートウェイ | 必要なネットワーク リソースを管理します | ノード リソース グループの共同作成者ロール | いいえ |
| アドオン | omsagent | AKS メトリックを Azure Monitor に送信します | 監視メトリック パブリッシャー ロール | いいえ |
| アドオン | 仮想ノード (ACIConnector) | Azure Container Instances に必要なネットワーク リソースを管理します | ノード リソース グループの共同作成者ロール | いいえ |
詳細については、「Azure Kubernetes Service でマネージド ID を使用する」を参照してください。
Kubernetes 用の Microsoft Entra ワークロード ID
Kubernetes ワークロードで、Azure Key Vault や Microsoft Graph などの、Microsoft Entra で保護されたリソースにアクセスするには、Microsoft Entra アプリケーションの資格情報が必要です。 開発者にとって共通の課題は、ソリューションのさまざまなコンポーネント間の通信をセキュリティで保護するシークレットと資格情報を管理することです。
Kubernetes 用の Microsoft Entra ワークロード ID を使うと、Azure Cosmos DB、Azure Key Vault、Azure Blob Storage などのクラウド サービスにアクセスするための資格情報を管理する必要がなくなります。 AKS ホステッド ワークロード アプリケーションでは、接続文字列、ユーザー名とパスワード、プライマリ キーなどの明示的な資格情報の代わりに Microsoft Entra セキュリティ トークンを使うことで、Microsoft Entra ワークロード ID を使って Azure マネージド サービスにアクセスできます。
次の図に示すように、Kubernetes クラスターは、Kubernetes サービス アカウントにトークンを発行するセキュリティ トークン発行者になります。 これらのトークンが Microsoft Entra アプリケーションで信頼されるように構成できます。 その後、 Azure Identity SDK または Microsoft 認証ライブラリ (MSAL)を使って、トークンを Microsoft Entra アクセス トークンと交換できます。
kubeletエージェントが、構成可能なファイル パスにあるワークロードにサービス アカウント トークンを提示します。- Kubernetes ワークロードは、提示された署名済みサービス アカウント トークンを Microsoft Entra ID に送信し、アクセス トークンを要求します。
- Microsoft Entra ID は OIDC 検出ドキュメントを使って、ユーザー定義マネージド ID または登録済みアプリケーションで信頼を調べて、受信したトークンを検証します。
- Microsoft Entra ID はセキュリティ アクセス トークンを発行します。
- Kubernetes ワークロードは、Microsoft Entra アクセス トークンを使って Azure リソースにアクセスします。
Kubernetes の Microsoft Entra ワークロード ID フェデレーションは、現在は Microsoft Entra アプリケーションでのみサポートされていますが、同じモデルが Azure マネージド ID に拡張される可能性があります。
Microsoft Entra ワークロード ID の詳細、自動化、ドキュメントについては、次をご覧ください。
- Azure ワークロード ID オープン ソース プロジェクト。
- ワークロード ID フェデレーション
- Kubernetes との Microsoft Entra ワークロード ID のフェデレーション
- 外部 OIDC ID プロバイダーとの Microsoft Entra ワークロード ID のフェデレーション
- 最小限の Microsoft Entra ワークロード ID のフェデレーション
- Microsoft Entra ワークロード ID
- Microsoft Entra ワークロード ID クイック スタート
- .NET Standard アプリケーションのユーザー割り当てマネージド ID で Kubernetes 用の Microsoft Entra ワークロード ID を使用する
ワークロードの例
この例のワークロードでは、AKS クラスターでフロントエンドとバックエンドのサービスを実行します。 ワークロード サービスは、Microsoft Entra セキュリティ トークンを使うことで、Microsoft Entra ワークロード ID を使って次の Azure サービスにアクセスします。
- Azure Key Vault
- Azure Cosmos DB
- Azure ストレージ アカウント
- Azure Service Bus 名前空間
前提条件
- OIDC 発行者 が有効になっている AKS クラスターを設定します。
- Mutating Admission Webhook をインストールします。
- ワークロードの Kubernetes サービス アカウントを作成します。
- クイックスタートで示されているように、Microsoft Entra アプリケーションを作成します。
- 必要な Microsoft Entra 登録済みアプリケーションに、適切なアクセス許可を持つロールを割り当てます。
- Microsoft Entra アプリケーションとサービス アカウントの発行者およびサブジェクトの間に、 フェデレーション ID 資格情報 を確立します。
- AKS クラスターにワークロード アプリケーションをデプロイします。
Microsoft Entra ワークロード ID のメッセージ フロー
AKS アプリケーションは、AKS クラスターの OIDC 発行者 からサービス アカウントのセキュリティ トークンを取得します。 Microsoft Entra ワークロード ID はセキュリティ トークンと Microsoft Entra ID によって発行されたセキュリティ トークンを交換し、アプリケーションは Microsoft Entra ID によって発行されたセキュリティ トークンを使って Azure リソースにアクセスします。
次の図は、フロントエンドとバックエンドのアプリケーションが Microsoft Entra セキュリティ トークンを取得して、Azure のサービスとしてのプラットフォーム (PaaS) サービスを使用する方法を示したものです。
このアーキテクチャの Visio ファイル をダウンロードします。
- Kubernetes が、ポッドまたはデプロイの仕様に基づいて、ポッドにトークンを発行します (ノードでスケジュールされている場合)。
- ポッドは、OIDC によって発行されたトークンを Microsoft Entra ID に送信して、特定の
appIdとリソースに対する Microsoft Entra トークンを要求します。 - Microsoft Entra ID は、アプリケーションで信頼を調べて、受信したトークンを検証します。
- Microsoft Entra ID は、セキュリティ トークン
{sub: appId, aud: requested-audience}を発行します。 - ポッドは、Microsoft Entra トークンを使ってターゲットの Azure リソースにアクセスします。
Kubernetes クラスターで Microsoft Entra ワークロード ID をエンド ツー エンドで使用するには:
- トークンを発行し、それらのトークンを検証できるようにする OIDC 検出ドキュメントを発行するように AKS クラスターを構成します。
- Kubernetes トークンを信頼するように Microsoft Entra アプリケーションを構成します。
- 開発者が、Kubernetes サービス アカウントを使用して Kubernetes トークンを取得するようにデプロイを構成します。
- Microsoft Entra ワークロード ID は、Kubernetes トークンを Microsoft Entra トークンと交換します。
- AKS クラスター ワークロードは、Microsoft Entra トークンを使って、Microsoft Graph などの保護されたリソースにアクセスします。
共同作成者
この記事は、Microsoft によって保守されています。 当初の寄稿者は以下のとおりです。
プリンシパルの作成者:
- Paolo Salvatori | プリンシパル サービス エンジニア
- Martin Gjoshevski | シニア サービス エンジニア
その他の共同作成者:
- Laura Nicolas | シニア ソフトウェア エンジニア
- Chad Kittel | プリンシパル ソフトウェア エンジニア
- Ed Price | シニア コンテンツ プログラム マネージャー
- Theano Petersen | テクニカル ライター
パブリックでない LinkedIn プロファイルを表示するには、LinkedIn にサインインします。
次のステップ
- AKS for Amazon EKS プロフェッショナル
- Kubernetes の監視とログ記録
- Kubernetes へのネットワーク アクセスをセキュリティで保護する
- Kubernetes クラスターのストレージ オプション
- Kubernetes のコスト管理
- Kubernetes のノードとノード プールの管理
- クラスターのガバナンス
- AWS に対する Microsoft Entra の ID 管理とアクセス管理