Configurer Live Data dans Container Insights

Article
11/05/2024

Si vous voulez voir les données actives avec Container Insights à partir de clusters Azure Kubernetes Service (AKS), configurez l’authentification pour accorder l’autorisation d’accéder à vos données Kubernetes. Cette configuration de sécurité autorise l’accès en temps réel à vos données via l’API Kubernetes, directement dans le portail Azure.

Cette fonctionnalité prend en charge les méthodes suivantes de contrôle d’accès aux journaux, événements et métriques :

AKS sans autorisation de contrôle d’accès en fonction du rôle (RBAC) Kubernetes activée
AKS activé avec autorisation Kubernetes RBAC
- AKS configuré avec la liaison de rôle de cluster clusterMonitoringUser
AKS activé avec l’authentification unique Microsoft Entra basée sur le protocole SAML

Ces instructions nécessitent un accès administratif à votre cluster Kubernetes. Si vous configurez Microsoft Entra ID afin de l’utiliser pour l’authentification utilisateur, vous devez également disposer d’un accès administratif à Microsoft Entra ID.

Cet article explique comment configurer l’authentification pour contrôler l’accès à la fonctionnalité Live Data à partir du cluster :

Cluster AKS sur lequel Kubernetes RBAC est activé
Cluster AKS intégré à Microsoft Entra

Modèle d’authentification

La fonctionnalité Live Data utilise l’API Kubernetes, qui est identique à l’outil en ligne de commande kubectl. Les points de terminaison de l’API Kubernetes utilisent un certificat auto-signé, que votre navigateur ne peut pas valider. Cette fonctionnalité utilise un proxy interne pour valider le certificat auprès du service AKS, garantissant ainsi que le trafic est approuvé.

Le portail Azure vous invite à valider vos informations de connexion pour un cluster Microsoft Entra ID. Il vous redirige vers la configuration de l’inscription du client lors de la création du cluster (inscription qui reconfigurée dans cet article). Ce comportement est similaire au processus d’authentification exigé par kubectl.

Notes

L’autorisation d’accès à votre cluster est managée par Kubernetes et le modèle de sécurité avec lequel elle est configurée. Les utilisateurs qui accèdent à cette fonctionnalité nécessitent l’autorisation de télécharger la configuration Kubernetes (kubeconfig), ce qui équivaut à exécuter az aks get-credentials -n {your cluster name} -g {your resource group}.

Ce fichier de configuration contient le jeton d’autorisation et d’authentification du Rôle utilisateur de cluster Azure Kubernetes Service, dans le cas où Azure RBAC est activé avec des clusters AKS sans autorisation Kubernetes RBAC activée. Il contient des informations sur Microsoft Entra ID et les détails d’inscription cliente lorsque AKS est activé avec l’authentification unique Microsoft Entra basée sur le protocole SAML.

L’utilisateur de cette fonctionnalité nécessite le Rôle utilisateur de cluster Azure Kubernetes afin d’accéder au cluster pour télécharger le fichier kubeconfig et utiliser cette fonctionnalité. Les utilisateurs n’ont pas besoin d’un accès contributeur au cluster pour utiliser cette fonctionnalité.

Utiliser clusterMonitoringUser avec des clusters prenant en charge Kubernetes RBAC

Pour éviter d’avoir à appliquer davantage de modifications de configuration afin de permettre à la liaison de rôle d’utilisateur Kubernetes clusterUser d’accéder à la fonctionnalité Live Data après l’activation de l’autorisation Kubernetes RBAC, AKS a ajouté une nouvelle liaison de rôle de cluster Kubernetes appelée clusterMonitoringUser. Cette liaison de rôle de cluster dispose par défaut de toutes les autorisations nécessaires pour accéder à l’API Kubernetes et aux points de terminaison en vue de l’utilisation de la fonctionnalité Live Data.

Pour utiliser la fonctionnalité Live Data avec ce nouvel utilisateur, vous devez être membre du rôle Utilisateur de cluster Azure Kubernetes Service ou Contributeur sur la ressource de cluster AKS. Quand la fonctionnalité Container Insights est activée, elle est configurée pour s’authentifier en utilisant clusterMonitoringUser par défaut. Si la liaison de rôle clusterMonitoringUser n’existe pas sur un cluster, clusterUser est utilisée à des fins d’authentification à la place. Le rôle de contributeur vous donne accès à clusterMonitoringUser (s’il existe) et le rôle d’utilisateur de cluster Azure Kubernetes Service vous donne accès à clusterUser. Chacun de ces deux rôles donne un accès suffisant pour utiliser cette fonctionnalité.

AKS ayant publié cette nouvelle liaison de rôle en janvier 2020, les clusters créés avant janvier 2020 ne l’ont pas. Si vous avez un cluster qui a été créé avant janvier 2020, vous pouvez y ajouter la nouvelle liaison clusterMonitoringUser en y effectuant une opération PUT. Vous pouvez également effectuer toute autre opération sur le cluster qui réalise une opération PUT sur ce dernier, telle que la mise à jour de la version du cluster.

Cluster Kubernetes sans contrôle Kubernetes RBAC activé

Si votre cluster Kubernetes n’est pas configuré avec l’autorisation Kubernetes RBAC (contrôle d’accès en fonction du rôle) ni intégré à l’authentification unique Microsoft Entra, il est inutile de suivre ces étapes. Vous disposez déjà d’autorisations d’administration par défaut dans une configuration non-RBAC.

Configurer une autorisation Kubernetes RBAC

Quand vous activez l’autorisation RBAC de Kubernetes, clusterUser et clusterAdmin sont utilisés pour accéder à l’API Kubernetes. Cette configuration revient à exécuter az aks get-credentials -n {cluster_name} -g {rg_name} sans l’option d’administration. Pour cette raison, clusterUser doit avoir accès aux points de terminaison dans l’API Kubernetes.

Les exemples d’étapes suivants montrent comment configurer la liaison de rôle de cluster à partir de ce modèle de configuration YAML.

Copiez et collez le fichier YAML, puis enregistrez-le sous le nom 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

Pour mettre à jour votre configuration, exécutez la commande kubectl apply -f LogReaderRBAC.yaml.

Notes

Si vous avez appliqué une version précédente du fichier LogReaderRBAC.yaml à votre cluster, mettez-la à jour en copiant et en collant le nouveau code indiqué à l’étape 1. Exécutez ensuite la commande mentionnée à l’étape 2 pour l’appliquer à votre cluster.

Configurer l’authentification intégrée de Microsoft Entra

Un cluster AKS configuré pour utiliser Microsoft Entra ID pour l’authentification utilisateur se sert des informations de connexion de la personne qui accède à cette fonctionnalité. Dans cette configuration, vous pouvez vous connecter à un cluster AKS en utilisant votre jeton d’authentification Microsoft Entra.

L’inscription cliente Microsoft Entra doit être reconfigurée pour permettre au portail Azure de rediriger les pages d’autorisation sous forme d’URL de redirection fiable. Les utilisateurs de Microsoft Entra ID se voient alors accorder un accès direct aux mêmes points de terminaison de l’API Kubernetes par le biais de ClusterRoles et de ClusterRoleBindings.

Pour plus d’informations sur la configuration de la sécurité avancée dans Kubernetes, consultez la documentation de Kubernetes.

Remarque

Si vous créez un nouveau cluster Kubernetes prenant en charge RBAC, consultez la page Intégrer Microsoft Entra ID à Azure Kubernetes Service et suivez les étapes pour configurer l’authentification Microsoft Entra. Pendant les étapes de création de l’application cliente, une remarque dans cette section met en évidence les deux URL de redirection que vous devez créer pour Container Insights, correspondant à celles spécifiées à l’étape 3.

Reconfiguration de l’inscription cliente

Localisez l’inscription cliente de votre cluster Kubernetes dans Microsoft Entra ID sous Microsoft Entra ID>Inscriptions d’applications dans le portail Azure.
Dans le volet gauche, sélectionnez Authentification.
Ajoutez deux URL de redirection à cette liste, en tant que types d’application web. La première valeur de l’URL de base doit être https://afd.hosting.portal.azure.net/monitoring/Content/iframe/infrainsights.app/web/base-libs/auth/auth.html. La deuxième valeur de l’URL de base doit être https://monitoring.hosting.portal.azure.net/monitoring/Content/iframe/infrainsights.app/web/base-libs/auth/auth.html.

Notes

Si vous utilisez cette fonctionnalité dans Microsoft Azure opéré par 21Vianet, la première valeur de l’URL de base doit être https://afd.hosting.azureportal.chinaloudapi.cn/monitoring/Content/iframe/infrainsights.app/web/base-libs/auth/auth.html. La deuxième valeur de l’URL de base doit être https://monitoring.hosting.azureportal.chinaloudapi.cn/monitoring/Content/iframe/infrainsights.app/web/base-libs/auth/auth.html.
Après avoir inscrit les URL de redirection, sous Octroi implicite, sélectionnez les options Jetons d’accès et Jetons d’ID. Ensuite, enregistrez vos modifications.

Vous pouvez configurer l’authentification avec Microsoft Entra ID pour l’authentification unique uniquement pendant le déploiement initial d’un nouveau cluster AKS. Vous ne pouvez pas configurer l’authentification unique pour un cluster AKS qui est déjà déployé.

Important

Si vous avez reconfiguré Microsoft Entra ID pour l’authentification utilisateur en utilisant l’URI mis à jour, effacez le cache de votre navigateur pour vous assurer que le jeton d’authentification mis à jour est téléchargé et appliqué.

Accorder l’autorisation

Chaque compte Microsoft Entra doit disposer de l’autorisation d’accès à la fonctionnalité Live Data sur les API appropriées dans Kubernetes. Les étapes de cet octroi au compte Microsoft Entra sont similaires à celles décrites dans la section Authentification RBAC de Kubernetes. Avant d’appliquer le modèle de configuration YAML à votre cluster, remplacez clusterUser sous ClusterRoleBinding par l’utilisateur souhaité.

Important

Si l’utilisateur auquel vous accordez la liaison RBAC Kubernetes figure dans le même locataire Microsoft Entra, attribuez des autorisations en fonction de userPrincipalName. Si l’utilisateur se trouve dans un autre locataire Microsoft Entra, recherchez et utilisez la propriété objectId.

Pour obtenir de l’aide supplémentaire sur la configuration de ClusterRoleBinding de votre cluster AKS, consultez Créer une liaison RBAC Kubernetes.

Étapes suivantes

L’authentification étant configurée, vous pouvez afficher les métriques ainsi que les événements et journaux en temps réel depuis votre cluster.

Partage via