Container insights でライブデータを構成する

[アーティクル]
11/05/2024

Azure Kubernetes Service (AKS) クラスターから、Container insights でライブデータを表示するには、Kubernetes データにアクセスするためのアクセス許可を付与する認証を構成します。このセキュリティ構成により、Azure portal で直接 Kubernetes API を介してデータにリアルタイムでアクセスできるようになります。

この機能では、ログ、イベント、メトリックへのアクセスを制御する次の方法がサポートされています。

Kubernetes ロールベースのアクセス制御 (RBAC) 承認が有効になっていない AKS
Kubernetes RBAC 認証を使って AKS が有効
- クラスタロールのバインディング clusterMonitoringUser で構成された AKS
Microsoft Entra の SAML ベースのシングルサインオンを使って AKS が有効

これらの手順では、Kubernetes クラスターへの管理アクセスが必要です。ユーザー認証に Microsoft Entra ID を使用するように構成する場合は、Microsoft Entra ID への管理アクセスも必要です。

この記事では、次のクラスターからのライブデータ機能へのアクセスを制御する認証を構成する方法について説明します。

Kubernetes RBAC が有効の AKS クラスター
Microsoft Entra 統合 AKS クラスター

認証モデル

ライブデータ機能では Kubernetes API を使用します。これは、kubectl コマンドラインツールと同じです。 Kubernetes API エンドポイントは、ブラウザーが検証できない自己署名証明書を使用します。この機能では、内部プロキシを使用して AKS サービスで証明書を検証し、トラフィックが信頼できることを確認します。

Azure portal で、Microsoft Entra ID クラスターのサインイン資格情報を検証するように求められます。これにより、クラスターの作成時にクライアント登録のセットアップにリダイレクトされます (この記事では再構成されています)。この動作は、kubectl で必要な認証プロセスに似ています。

Note

クラスターに対する承認は、Kubernetes および Kubernetes で構成されているセキュリティモデルによって管理されます。この機能にアクセスするユーザーには、az aks get-credentials -n {your cluster name} -g {your resource group} を実行する場合と同様に、Kubernetes 構成 (kubeconfig) をダウンロードするためのアクセス許可が必要です。

Azure RBAC 対応の AKS クラスターと Kubernetes RBAC 認証が有効になっていない AKS クラスターの場合、この構成ファイルには、Azure Kubernetes Service クラスターユーザーロールの承認および認証トークンが含まれます。 Microsoft Entra の SAML ベースのシングルサインオンで AKS が有効になっている場合は、Microsoft Entra ID とクライアント登録の詳細情報が含まれます。

この機能のユーザーには、kubeconfig をダウンロードしてこの機能を使用するために、クラスターにアクセスするための Azure Kubernetes クラスターユーザーロールが必要です。この機能を使用するユーザーには、クラスターに対する共同作成者アクセス権は "不要" です。

Kubernetes RBAC が有効なクラスターで clusterMonitoringUser を使用する

Kubernetes RBAC 承認を有効化した後に、Kubernetes ユーザーロールのバインディング clusterUser でライブデータ機能へのアクセスを許可するために、さらに構成変更を適用する必要がないようにするため、AKS には clusterMonitoringUser と呼ばれる新しい Kubernetes クラスターロールバインディングが追加されました。このクラスターロールバインディングには、Kubernetes API にアクセスするために必要なすべてのアクセス許可と、ライブデータ機能を使用するためのエンドポイントが含まれています。

この新しいユーザーでライブデータ機能を使用するには、AKS クラスターリソースの Azure Kubernetes Service Cluster の User または Contributor ロールのメンバーである必要があります。 Container insights (有効化されている場合) は、既定で clusterMonitoringUser を使用して認証するように構成されます。クラスターに clusterMonitoringUser ロールのバインドが存在しない場合は、代わりに clusterUser が認証に使用されます。共同作成者の場合、clusterMonitoringUser (存在する場合) にアクセスできるようになります。Azure Kubernetes Service クラスターユーザーの場合、clusterUser にアクセスできるようになります。これら 2 つのロールのいずれにも、この機能を使用するための十分なアクセス権が付与されます。

AKS は 2020 年 1 月にこの新しいロールバインドをリリースしたため、2020 年 1 月より前に作成されたクラスターには存在しません。 2020 年の 1 月より前に作成されたクラスターがある場合、クラスター上で PUT 操作を実行することで、新しい clusterMonitoringUser を既存のクラスターに追加できます。または、クラスターのバージョンの更新など、クラスターで PUT 操作を実行するその他の操作をクラスターで実行することもできます。

Kubernetes RBAC なしの Kubernetes クラスターが有効

お使いの Kubernetes クラスターが Kubernetes RBAC 認証で構成されていない場合、または Microsoft Entra シングルサインオンと統合されていない場合は、これらの手順に従う必要はありません。非 RBAC 構成では、管理アクセス許可が既定で付与されます。

Kubernetes RBAC 認証の構成

Kubernetes RBAC 認証を有効にすると、Kubernetes API にアクセスするために clusterUser と clusterAdmin が使用されます。この構成は、管理オプションなしで az aks get-credentials -n {cluster_name} -g {rg_name} 実行する場合と同様です。このため、clusterUser には Kubernetes API のエンドポイントへのアクセス権を付与する必要があります。

次の例の手順は、この YAML 構成テンプレートからクラスターロールバインディングを構成する方法を示しています。

YAML ファイルをコピーして貼り付け、LogReaderRBAC.yaml として保存します。

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
   name: containerHealth-log-reader
rules:
    - apiGroups: ["", "metrics.k8s.io", "extensions", "apps"]
      resources:
         - "pods/log"
         - "events"
         - "nodes"
         - "pods"
         - "deployments"
         - "replicasets"
      verbs: ["get", "list"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
   name: containerHealth-read-logs-global
roleRef:
   kind: ClusterRole
   name: containerHealth-log-reader
   apiGroup: rbac.authorization.k8s.io
subjects:
- kind: User
  name: clusterUser
  apiGroup: rbac.authorization.k8s.io

構成を更新するには、コマンド kubectl apply -f LogReaderRBAC.yaml を実行します。

注意

以前のバージョンの LogReaderRBAC.yaml ファイルをクラスターに適用した場合は、手順 1. に示す新しいコードをコピーして貼り付けて更新します。次に、手順 2 に示すコマンドを実行して、クラスターに適用します。

Microsoft Entra 統合認証を構成する

ユーザー認証に Microsoft Entra ID を使用するように構成された AKS クラスターでは、この機能にアクセスするユーザーのサインイン資格情報を使用します。この構成では、Microsoft Entra 認証トークンを使って AKS クラスターにサインインできます。

Azure portal が信頼されたリダイレクト URL として承認ページをリダイレクトできるように、Microsoft Entra クライアント登録を再構成する必要があります。その後、Microsoft Entra ID のユーザーは、ClusterRoles と ClusterRoleBindings を使用して、同じ Kubernetes API エンドポイントへの直接アクセスを許可されます。

Kubernetes での高度なセキュリティ設定の詳細については、Kubernetes のドキュメントをご覧ください。

Note

新しい Kubernetes RBAC 対応クラスターを作成する場合は、「Microsoft Entra ID と Azure Kubernetes Service を統合する」を参照し、手順に従って Microsoft Entra 認証を構成してください。クライアントアプリケーションを作成する手順の該当するセクションの注で、Container insights 用に作成する必要がある、手順 3 で指定するものと一致する 2 つのリダイレクト URL が強調されています。

クライアント登録の再構成

Azure portal の [Microsoft Entra ID]>[アプリの登録] で、Microsoft Entra ID の Kubernetes クラスターのクライアント登録を見つけます。
左側のペインで、[認証] を選択します。
Web アプリケーションの種類として、この一覧に 2 つのリダイレクト URL を追加します。最初のベース URL は、https://afd.hosting.portal.azure.net/monitoring/Content/iframe/infrainsights.app/web/base-libs/auth/auth.html である必要があります。 2 つ目のベース URL は、https://monitoring.hosting.portal.azure.net/monitoring/Content/iframe/infrainsights.app/web/base-libs/auth/auth.html である必要があります。

注意

この機能を 21Vianet によって運営される Microsoft Azure で使用する場合は、最初のベース URL の値を https://afd.hosting.azureportal.chinaloudapi.cn/monitoring/Content/iframe/infrainsights.app/web/base-libs/auth/auth.html にする必要があります。 2 つ目のベース URL は、https://monitoring.hosting.azureportal.chinaloudapi.cn/monitoring/Content/iframe/infrainsights.app/web/base-libs/auth/auth.html である必要があります。
リダイレクト URL を登録したら、[暗黙的な許可] で [アクセストークン] と [ID トークン] の各オプションを選択します。次に、変更を保存します。

新しい AKS クラスターの初期デプロイ中にのみ、シングルサインオン用に Microsoft Entra ID で認証を構成できます。既にデプロイされている AKS クラスターに対して、シングルサインオンを構成することはできません。

重要

更新された URI を使用したユーザー認証のために Microsoft Entra ID を再構成した場合は、ブラウザーのキャッシュをクリアして、更新された認証トークンが確実にダウンロードおよび適用されるようにします。

アクセス許可を付与する

ライブデータ機能にアクセスするには、各 Microsoft Entra アカウントに Kubernetes の適切な API へのアクセス許可を付与する必要があります。 Microsoft Entra アカウントに付与する手順は、Kubernetes RBAC 認証のセクションで説明する手順と似ています。 YAML 構成テンプレートをクラスターに適用する前に、ClusterRoleBinding の clusterUser を目的のユーザーに置き換えます。

重要

Kubernetes RBAC のバインドの付与先となるユーザーが同じ Microsoft Entra テナントに存在する場合は、userPrincipalName に基づいてアクセス許可を割り当てます。ユーザーが別の Microsoft Entra テナントに存在する場合は、objectId プロパティを照会して使用します。

AKS クラスターの ClusterRoleBinding の構成に関するさらなるヘルプについては、「Kubernetes RBAC のバインドを作成する」をご覧ください。

次の手順

認証を設定したので、メトリックと、イベントおよびログをクラスターからリアルタイムで表示できます。

次の方法で共有

Container insights でライブデータを構成する

認証モデル

Kubernetes RBAC が有効なクラスターで clusterMonitoringUser を使用する

Kubernetes RBAC なしの Kubernetes クラスターが有効

Kubernetes RBAC 認証の構成

Microsoft Entra 統合認証を構成する

クライアント登録の再構成

アクセス許可を付与する

次の手順

フィードバック

その他のリソース

次の方法で共有

Container insights でライブ データを構成する

認証モデル

Kubernetes RBAC が有効なクラスターで clusterMonitoringUser を使用する

Kubernetes RBAC なしの Kubernetes クラスターが有効

Kubernetes RBAC 認証の構成

Microsoft Entra 統合認証を構成する

クライアント登録の再構成

アクセス許可を付与する

次の手順

フィードバック

その他のリソース

Container insights でライブデータを構成する