AKS 構造化認証で外部 ID プロバイダーを使用する (プレビュー)

Azure Kubernetes Service (AKS) では構造化認証がサポートされています。これにより、Kubernetes API サーバーに対してユーザーを認証するための外部 ID プロバイダーを構成できます。 この機能は、アップストリームの Kubernetes 構造化認証構成に基づいています。 AKS は、構成に従って外部 ID プロバイダーからのトークンを検証する JSON Web トークン (JWT) 認証子を介してこの機能を実装します。 構造化認証を使用すると、組織は AKS を Microsoft Entra ID を超える既存の ID インフラストラクチャと統合できます。

この記事では、主要な概念、セキュリティに関する考慮事項、構成の次の手順など、AKS 構造化認証で外部 ID プロバイダーを使用する方法の概要について説明します。

外部 ID プロバイダー認証の利点

構造化認証は、業界標準の OpenID Connect (OIDC) ID プロバイダーをサポートすることで、従来の Microsoft Entra ID 統合を超えて AKS を拡張します。 この機能では次のことができます。

• Google、GitHub、OIDC 準拠プロバイダーなどの外部 ID プロバイダーを使用してユーザーを認証します。
• 組織全体で一元化された ID 管理を維持します。
• カスタム要求の検証規則とユーザー マッピング規則を実装します。
• 1 つのクラスターで複数の ID プロバイダーを同時にサポートします。

外部 ID プロバイダーの認証フロー

ユーザーが外部 ID プロバイダーによる構造化認証を使用して Kubernetes API サーバーにアクセスしようとすると、認証と承認のフローは次のようになります。

• 認証: 次の手順では、ユーザーの ID を検証します。
  • トークンの表示: ユーザーは、構成された ID プロバイダーから JWT トークンを提示します。
  • トークンの検証: API サーバーは、トークンの署名、発行者、対象ユーザー、および有効期限を検証します。
  • 要求の処理: カスタム要求検証規則が適用され、トークンが要件を満たしていることを確認します。
  • ユーザー マッピング: 要求は Kubernetes ユーザー ID (ユーザー名、グループ、および追加の属性) にマップされます。
• 承認: Standard Kubernetes Role-Based アクセス制御 (RBAC) によって、認証されたユーザーが実行できるアクションが決まります。

サポートされているアイデンティティプロバイダ

AKS 構造化認証では OIDC 準拠の ID プロバイダーが許可されますが、一般的なプロバイダーには次のようなものがあります。

• GitHub: GitHub ID または GitHub Actions を使用して認証します。
• Google OAuth 2.0: 認証には Google アカウントを使用します。
• 汎用 OIDC プロバイダー: OIDC 標準を実装するすべてのプロバイダー。
• カスタム ID ソリューション: 組織固有の OIDC 実装。

外部 ID プロバイダーの要件

AKS 構造化認証を使用するには、外部 ID プロバイダーが次の要件を満たしている必要があります。

• OIDC 標準をサポートします。
• パブリックにアクセスできる OIDC 検出エンドポイントを提供します。
• 適切な要求で JWT トークンを発行します。
• トークン検証のために AKS クラスター ノードからアクセスできます。

AKS 構造化認証用の JWT 認証子

JWT 認証子は、AKS が外部 ID プロバイダーからのトークンを検証および処理する方法を定義する構成オブジェクトです。 たとえば、AKS では、 aud (対象ユーザー) 要求が、認証システムに対して構成した対象ユーザー値 ( "my-api"、OAuth クライアント ID など) と一致する ID トークン (JWT) が必要です。 各 JWT 認証システムには、次のコンポーネントが含まれています。

• 発行者の構成: OIDC 発行者の URL とトークンの予想される対象ユーザーの値を指定します。
• 要求の検証規則: CEL (共通式言語) 式を使用して、トークン要求にカスタム検証ロジックを適用します。
• 要求マッピング: JWT 要求を Kubernetes ユーザー属性 (ユーザー名、グループ、追加フィールドなど) にマップする方法を定義します。
• ユーザー検証規則: 要求マッピング後に追加の検証ロジックを適用して、アクセスをさらに制限または許可します。

要求の検証とマッピングのための CEL 式

構造化認証では、 柔軟 な要求の検証とマッピングに CEL 式を使用します。 CEL は、JWT 要求に対してカスタム ロジックを評価するためのセキュリティで保護されたサンドボックス環境を提供します。

CEL 式の例:

// Validate that the 'sub' claim exists
has(claims.sub)

// Map username with AKS prefix
'aks:jwt:' + claims.sub

// Map groups from comma-separated string
claims.groups.split(',').map(g, 'aks:jwt:' + g)

// Conditional mapping based on claim verification
'aks:jwt:' + (claims.email_verified ? claims.email : claims.sub)

セキュリティのベスト プラクティス

AKS 構造化認証で外部 ID プロバイダーを使用する場合は、次のセキュリティのベスト プラクティスに留意してください。

• 強力な要求の検証を使用する: 承認されたトークンのみが受け入れられるように、包括的な検証規則を実装します。
• トークン スコープを制限する: 必要最小限の要求でトークンを発行するように ID プロバイダーを構成します。
• 定期的なローテーション: クライアント シークレットと証明書を定期的にローテーションします。
• アクセスの監視: リソース ログ を有効にし、 kube-apiserver ログを有効にして、構成された JWT 認証子に関する潜在的な問題を検査し、認証イベントを追跡します。
• テスト構成: 最初に非運用環境で JWT 認証子の構成を検証します。

セキュリティに関する考慮事項

AKS 構造化認証で外部 ID プロバイダーを使用する場合は、次のセキュリティに関する考慮事項に留意してください。

• プレフィックスの要件: 他の認証方法やシステム アカウントとの競合を防ぐために、構造化認証によってマップされるすべてのユーザー名とグループの前に aks:jwt: を付ける必要があります。
• ネットワーク アクセス: ID プロバイダー エンドポイントには、次の場所からアクセスできる必要があります。
  • トークン検証用の AKS クラスター ノード。
  • トークン取得用のクライアント システム。
  • 認証フローに関係するすべてのネットワーク パス。
• 検証レイヤー: 構造化認証では、複数の検証レイヤーが提供されます。
  • トークン署名の検証 により、トークンの信頼性が保証されます。
  • 標準要求検証 では、発行者、対象ユーザー、有効期限が検証されます。
  • カスタム要求の検証 は、組織の特定の要件を適用します。
  • 要求マッピング後のユーザー検証の最終チェック。

関連するコンテンツ

構造化認証と関連する機能の詳細については、次のリソースを参照してください。

• AKS の構造化認証を構成する
• Kubernetes 構造化認証の構成
• Kubernetes の CEL 式
• OpenID Connect の仕様