この記事では、Amazon Elastic Kubernetes Service (EKS) と Azure Kubernetes Service (AKS) によって、Kubernetes ワークロードがクラウド プラットフォーム サービスにアクセスするための ID を提供する方法について説明します。 アマゾン ウェブ サービス (AWS) の ID およびアクセス管理 (IAM) と Microsoft Entra ID の詳細な比較については、次のリソースを参照してください。
このガイドでは、AKS クラスター、組み込みサービス、アドオンがマネージド ID を使用して、ロード バランサーやマネージド ディスクなどの Azure リソースにアクセスする方法について説明します。 また、この記事では、AKS ワークロードが接続文字列、アクセス キー、またはユーザー資格情報を必要とせずに Azure リソースにアクセスできるように、Microsoft Entra Workload ID を使用する方法についても説明します。
注
この記事は、Amazon EKS に精通している専門家が Azure Kubernetes Service (AKS) を理解するのに役立つ一連の記事の一部です。
Amazon EKS の ID とアクセスの管理
Amazon EKS では、Kubernetes ポッド内での ID およびアクセス管理のためのネイティブ オプションが用意されています。 これらのオプションには、サービス アカウントの IAM ロールや Amazon EKS のサービスリンク ロールが含まれます。
サービス アカウントの IAM ロール
IAM ロールを Kubernetes サービス アカウントに関連付けることができます。 この関連付けにより、そのサービス アカウントを使用するすべてのポッド内のコンテナに AWS のアクセス許可が付与されます。 サービス アカウントの IAM ロールには、次の利点があります。
最小権限: 特定の IAM アクセス許可をサービス アカウントに割り当てることで、そのサービス アカウントを使用するポッドのみにアクセス許可を与えることができます。 この構成により、ノード上のすべてのポッドに対して、ノード IAM ロールへの拡張アクセス許可の付与が不要になります。 この方法により、セキュリティが強化され、きめ細かい制御が可能になり、kube2iam などのパートナー ソリューションが不要になります。 詳細については、「サービス アカウントの IAM ロール」を参照してください。
資格情報の分離: ポッド内の各コンテナは、それぞれのサービス アカウントに関連付けられた IAM ロールの資格情報のみを取得できます。 この分離により、コンテナは別のポッド内の他のコンテナに属する資格情報にアクセスできなくなります。
監査可能性: Amazon EKS は AWS CloudTrail を利用してアクセス ログとイベント ログを記録します。これにより、後日の監査やコンプライアンスへの対応が容易になります。
詳細については、「サービス アカウントの IAM ロール」を参照してください。
Amazon EKS のサービスリンク ロール
Amazon EKS のサービスリンク ロール は、Amazon EKS に直接リンクされる一意の IAM ロールです。 これらの定義済みロールには、関連付けられたロールに代わって AWS サービスを呼び出すために必要なアクセス許可が含まれています。 Amazon EKS の主要なサービスリンク ロールは Amazon EKS ノードの IAM ロールです。
Amazon EKS ノードの kubelet
デーモンは、Amazon EKS ノード IAM ロールを使用して、ノードに代わって AWS のサービスへの API 呼び出しを行います。 IAM インスタンス プロファイルとそれに関連付けられたポリシーによって、これらの API 呼び出しに必要なアクセス許可が付与されます。 この設定により、EKS クラスター内のノードに対する IAM ロールの管理がシンプルになります。
詳細については、「Amazon EKS のサービスリンク ロールを使用する」を参照してください。
ID およびアクセス管理に関する詳細情報
サービス アカウントの IAM ロールや Amazon EKS のサービスリンク ロールに加え、Amazon EKS における ID およびアクセス管理には他にも重要な要素があります。
Amazon EKS の RBAC 認可: Amazon EKS はロールベースのアクセス制御 (RBAC) をサポートしています。 この機能を使用して、クラスター内の Kubernetes リソースに対してきめ細かなアクセス許可を定義できます。
AWS IAM: IAM は、EKS など AWS のサービス向けの包括的な ID 管理ソリューションを提供します。 IAM を使用してユーザー、グループ、ロールを作成し管理して、EKS リソースへのアクセスを制御します。
Amazon EKS のセキュリティ グループ: Amazon EKS を使用して、クラスター内で稼働するポッドにセキュリティ グループ規則を適用します。 この機能を使用して、受信および送信トラフィックを制御します。
詳細については、「Amazon EKS とは」を参照してください。
AKS クラスターのマネージド ID
AKS クラスターが Azure リソース (ロードバランサーやマネージド ディスクなど) にアクセスするには、Microsoft Entra ID が必要です。 AKS クラスターから他の Azure サービスへのアクセスを認可するには、Azure リソースのマネージド ID を使用することをお勧めします。
マネージド ID の種類
開発者は、サービス間通信のセキュリティ確保に必要なシークレット、資格情報、証明書、キーの管理に苦労することがよくあります。 マネージド ID により、開発者はこれらの資格情報を管理する必要がなくなります。 マネージド ID を使用すると、資格情報を管理したりコードに埋め込んだりせずに AKS クラスターを認証できます。 Azure のリソースに対するアクセス許可を ID に付与するには、その ID に Azure RBAC ロールを割り当てます。
マネージド ID には次の 2 種類があります。
システム割り当て。 仮想マシンなどの一部の Azure リソースでは、リソースでマネージド ID を直接有効にすることができます。 システム割り当てマネージド ID を有効にする場合:
この ID 用に Microsoft Entra ID で特殊な種類のサービス プリンシパルが作成されます。 サービス プリンシパルは、その Azure リソースのライフサイクルに関連付けられています。 Azure リソースが削除されると、Azure によりこのサービス プリンシパルが自動的に削除されます。
その Azure リソースのみが、その ID を使用して Microsoft Entra ID にトークンを要求できます。
マネージド ID が 1 つ以上のサービスにアクセスすることを承認します。
システム割り当てサービス プリンシパルの名前は、それが作成された Azure リソースの名前と同じです。
ユーザー割り当て。 スタンドアロンの Azure リソースとしてマネージド ID を自分で作成することもできます。 ユーザー割り当てマネージド ID を作成して、1 つ以上の Azure リソースに割り当てることができます。 ユーザー割り当てマネージド ID を有効にする場合:
この ID 用に Microsoft Entra ID で特殊な種類のサービス プリンシパルが作成されます。 サービス プリンシパルは、それを使うリソースとは別に管理されます。
複数のリソースで使用できます。
マネージド ID が 1 つ以上のサービスにアクセスすることを承認します。
どちらの種類のマネージド ID も、AKS クラスターから Azure リソースへのアクセスを認可するために使用できます。
詳細については、マネージド ID の種類に関するページを参照してください。
AKS でのマネージド ID
AKS クラスターでは、次の種類のマネージド ID を使用できます。
システム割り当てマネージド ID は、AKS クラスターなどの単一の Azure リソースに関連付けられます。 この ID はクラスターのライフサイクル中にのみ存在します。
ユーザー割り当てマネージド ID はスタンドアロンの Azure リソースであり、AKS クラスターから他の Azure サービスへのアクセスを認可するために使用できます。 この ID はクラスターとは別に存続し、複数の Azure リソースで使用できます。
事前に作成された kubelet マネージド ID は、省略可能なユーザー割り当て ID であり、kubelet が Azure の他のリソースにアクセスするために使用できます。 kubelet にユーザー割り当てマネージド ID を指定していない場合、AKS によってノード リソース グループ内にユーザー割り当て kubelet ID が作成されます。
AKS クラスターのマネージド ID を構成する
AKS クラスターをデプロイすると、システム割り当てマネージド ID が自動的に作成されます。 クラスターの作成時にユーザー割り当てマネージド ID を作成することもできます。 クラスターはこのマネージド ID を使用して Microsoft Entra ID にトークンを要求します。 このトークンによって、Azure 上で実行されている他のリソースへのアクセスが認可されます。
マネージド ID に Azure RBAC ロールを割り当てると、クラスターに特定のリソースへのアクセス許可を付与できます。 たとえば、Azure Key Vault 内のシークレットへのアクセスを許可する Azure RBAC ロールをマネージド ID に割り当てることができます。 この方法により、資格情報を管理することなく簡単に、クラスターへのアクセスを認可できます。
AKS におけるマネージド ID のメリットと管理
AKS でマネージド ID を使用すると、シークレットのプロビジョニングやローテーションが不要になります。 Azure が ID の資格情報を管理します。 そのため、追加のシークレットを管理することなく、アプリケーションからのアクセスを認可できます。
既にマネージド ID を使用している AKS クラスターがある場合は、そのクラスターを別の種類のマネージド ID に更新できます。 ただし、この更新により、コントロール プレーンのコンポーネントが新しい ID に切り替わるまで遅延が生じる可能性があります。 この処理には数時間かかることがあります。 この間、コントロール プレーンのコンポーネントは、古いトークンの有効期限が切れるまで古い ID を使い続けます。
AKS におけるマネージド ID の種類
AKS では、さまざまな組み込みサービスやアドオンを有効にするために、複数の種類のマネージド ID を使用します。
マネージド ID | 利用事例 | 既定のアクセス許可 |
---|---|---|
コントロール プレーン (システム割り当て) | AKS のコントロール プレーン コンポーネントは、この ID を使用してクラスター リソースを管理します。 対象となるリソースには、イングレス ロード バランサー、AKS マネージドのパブリック IP アドレス、クラスター オートスケーラーのほか、Azure ディスク/ファイル/Blob の CSI ドライバーなどがあります。 | ノード リソース グループの共同作成者ロール |
Kubelet (ユーザー割り当て) | Azure Container Registry での認証 | 該当なし (Kubernetes バージョン 1.15 以降) |
アドオン ID (AzureNPM、AzureCNI ネットワーク監視、Azure Policy、Calico) | これらのアドオンには ID は不要です。 | なし |
アプリケーション ルーティング | Azure DNS や Azure Key Vault の証明書を管理します。 | Key Vault のキー コンテナ シークレット ユーザー ロール、DNS ゾーンの DNS ゾーン共同作成者ロール、プライベート DNS ゾーンのプライベート DNS ゾーン共同作成者ロール |
イングレス アプリケーション ゲートウェイ | 必要なネットワーク リソースを管理します。 | ノード リソース グループの共同作成者ロール |
Operations Management Suite (OMS) エージェント | AKS メトリックを Azure Monitor に送信します。 | 監視メトリック パブリッシャー ロール |
仮想ノード (Azure Container Instances コネクタ) | Container Instances に必要なネットワーク リソースを管理します。 | ノード リソース グループの共同作成者ロール |
コスト分析 | コスト割り当てデータを収集します。 | なし |
Workload ID | Workload ID を使用してアプリケーションがクラウド リソースに安全にアクセスできるようにします。 | なし |
詳細については、AKS でのマネージド ID の使用に関するページを参照してください。
Kubernetes のワークロード ID
Workload ID は Kubernetes と統合されており、AKS クラスターにデプロイされたワークロードが Microsoft Entra によって保護されたリソース (Key Vault や Microsoft Graph など) にアクセスできるようにします。 Workload ID は Kubernetes ネイティブの機能を使用して外部の ID プロバイダーとフェデレーションします。 詳細については、「AKS で Workload ID を使用する」を参照してください。
Workload ID を使用するには、Kubernetes 内でサービス アカウントを構成します。 ポッドはこのサービス アカウントを使用して認証を行い、Azure リソースに安全にアクセスします。 Workload ID は Azure ID サービス クライアント ライブラリまたは Microsoft Authentication Library コレクションと併用できます。 ID に対するアクセス許可やアクセス制御を管理するには、Microsoft Entra ID にアプリケーションを登録する必要があります。
Kubernetes クラスターで Workload ID を十分に活用するには、トークンを発行するように AKS クラスターを構成し、トークン検証用の OpenID Connect (OIDC) Discovery ドキュメントを公開します。 詳細については、「AKS で OIDC プロバイダーを作成する」を参照してください。
Kubernetes トークンを信頼するように Microsoft Entra アプリケーションを構成する必要もあります。 その後、開発者は Kubernetes のサービス アカウントを使用してトークンを取得するようにデプロイを構成できます。 Workload ID はこれらのトークンを Microsoft Entra トークンと交換します。 AKS クラスターのワークロードは、これらの Microsoft Entra トークンを使用して、Azure 上の保護されたリソースに安全にアクセスできます。
次の図では、Kubernetes クラスターがどのようにして Kubernetes サービス アカウントにトークンを発行するセキュリティ トークン発行者になるかを示しています。 これらのトークンが Microsoft Entra アプリケーションで信頼されるように構成できます。 その後、Azure identity services SDK または Microsoft Authentication Library を使用して、トークンを Microsoft Entra アクセス トークンと交換できます。
kubelet
エージェントが、構成可能なファイル パスにあるワークロードにサービス アカウント トークンを提示します。Kubernetes ワークロードは、提示された署名済みサービス アカウント トークンを Microsoft Entra ID に送信し、アクセス トークンを要求します。
Microsoft Entra ID は OIDC Discovery ドキュメントを使用して、ユーザー定義マネージド ID または登録アプリケーションで信頼の可否を確認し、受信トークンを検証します。
Microsoft Entra ID はセキュリティ アクセス トークンを発行します。
Kubernetes ワークロードは、Microsoft Entra アクセス トークンを使用して Azure リソースにアクセスします。
Workload ID の詳細については、次のリソースを参照してください。
- Workload ID オープンソース プロジェクト
- Workload ID フェデレーション
- Workload ID と Kubernetes のフェデレーション
- Workload ID と外部 OIDC ID プロバイダーとのフェデレーション
- 最小限の Workload ID フェデレーション
- Workload ID のドキュメント
- Workload ID クイック スタート
- .NET Standard アプリケーションのユーザー割り当てマネージド ID で Workload ID for Kubernetes を使用する
ワークロードの例
以下の例に示すワークロードは AKS クラスター上で実行され、フロントエンド サービスとバックエンド サービスで構成されています。 これらのサービスは Workload ID を使用して、Azure Key Vault、Azure Cosmos DB、Azure Storage アカウント、Azure Service Bus 名前空間などの Azure サービスにアクセスします。 このワークロード例を設定するには、次の前提条件を満たしてください。
OIDC 発行者と Workload ID を有効にした AKS クラスターを設定します。
ワークロードの名前空間に Kubernetes サービス アカウントを作成します。
Microsoft Entra のユーザー割り当てマネージド ID または登録アプリケーションを作成します。
Microsoft Entra マネージド ID または登録アプリケーションとワークロードのサービス アカウントとの間にフェデレーション ID 資格情報を確立します。
必要なロールと適切なアクセス許可を Microsoft Entra マネージド ID または登録アプリケーションに割り当てます。
ワークロードをデプロイし、ワークロード ID を使用して認証を確認します。
Workload ID のメッセージ フロー
このワークロード例では、フロントエンドおよびバックエンドのアプリケーションが 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 クラスターで Workload ID をエンド ツー エンドで使用するには:
トークンを発行し、それらのトークンを検証できるようにする OIDC Discovery ドキュメントを発行するように AKS クラスターを構成します。
Kubernetes トークンを信頼するように Microsoft Entra アプリケーションを構成します。
開発者が、Kubernetes サービス アカウントを使用して Kubernetes トークンを取得するようにデプロイを構成します。
Workload ID は Kubernetes のトークンを Microsoft Entra トークンに交換します。
AKS クラスター ワークロードは、Microsoft Entra トークンを使用して、Microsoft Graph などの保護されたリソースにアクセスします。
貢献者
Microsoft では、この記事を保持しています。 次の共同作成者がこの記事を書きました。
主要な著者:
- Paolo Salvatori | プリンシパル サービス エンジニア
- Martin Gjoshevski | シニア サービス エンジニア
その他の共同作成者:
- Laura Nicolas | シニア ソフトウェア エンジニア
- チャド・キットテル |プリンシパル ソフトウェア エンジニア - Azure パターンとプラクティス
- Ed Price | シニア コンテンツ プログラム マネージャー
- Theano Petersen | テクニカル ライター
公開されていない LinkedIn プロフィールを見るには、LinkedIn にサインインしてください。
次のステップ
- AKS でサービス プリンシパルを使用する
- AKS でマネージド ID を使用する
- ラーニング パス: Microsoft Entra ID で ID およびアクセスを管理する