Architecture de Defender pour les conteneurs

  • 10 minutes

Defender pour les conteneurs est conçu différemment pour chaque environnement Kubernetes, où qu’il s’exécute :

  • Azure Kubernetes Service (AKS) - Service managé de Microsoft conçu pour le développement, le déploiement et la gestion d’applications conteneurisées.
  • Amazon Elastic Kubernetes Service (EKS) dans un compte Amazon Web Services (AWS) connecté - Service managé d’Amazon permettant d’exécuter Kubernetes sur AWS sans avoir à installer, utiliser et gérer votre propre plan de contrôle ou vos propres nœuds Kubernetes.
  • Google Kubernetes Engine (GKE) dans un projet Google Cloud Platform (GCP) connecté : l’environnement géré de Google pour le déploiement, la gestion et la mise à l’échelle d’applications à l’aide de l’infrastructure GCP.
  • Une distribution Kubernetes non managée (à l’aide de Kubernetes avec Azure Arc), des clusters Kubernetes certifiés CNCF (Cloud Native Computing Foundation) hébergés localement ou sur IaaS.

Pour protéger vos conteneurs Kubernetes, Defender pour les conteneurs reçoit et analyse les éléments suivants :

  • Journaux d’audit et événements de sécurité du serveur d’API
  • Informations de configuration du cluster provenant du plan de contrôle
  • Configuration de la charge de travail d’Azure Policy
  • Signaux et événements de sécurité au niveau du nœud

Architecture pour chaque environnement Kubernetes

Diagramme d’architecture des clusters Defender pour le cloud et AKS

Lorsque Defender pour le cloud protège un cluster hébergé dans Azure Kubernetes Service, le regroupement des données des journaux d'audit se fait sans agent et automatiquement via l'infrastructure Azure, sans coût supplémentaire ni considérations de configuration. Il s’agit des composants nécessaires afin de bénéficier de la protection totale offerte par Microsoft Defender pour les conteneurs :

  • Agent Defender : DaemonSet déployé sur chaque nœud qui collecte les signaux des hôtes à l’aide de la *technologie Extended Berkeley Packet Filter (eBPF)* et assure la protection du runtime. L’agent est inscrit auprès d’un espace de travail Log Analytics et utilisée comme un pipeline de données. Toutefois, les données du journal d’audit ne sont pas stockées dans l’espace de travail Log Analytics. L’agent Defender est déployé en tant que profil de sécurité AKS.

    • *Informations sur eBPF* : La technologie Extended Berkeley Packet Filter (eBPF) est une infrastructure puissante et polyvalente au sein du noyau Linux pour analyseret filtrer des paquets réseau par programmation, ainsi que pour effectuer diverses autres tâches au niveau du système. Initialement basé sur le Berkeley Packet Filter (BPF) introduit dans les années 1990, eBPF développe ses fonctionnalités en permettant aux programmes définis par l’utilisateur de s’exécuter dans le noyau, ce qui permet un traitement dynamique et efficace des paquets sans nécessiter de modifications au noyau lui-même.
    • Les programmes eBPF sont écrits dans un sous-ensemble restreint du langage C et sont chargés dans le noyau, où ils s’exécutent dans un environnement sécurisé et en bac à sable. Cela permet d’effectuer une large gamme de tâches liées au réseau directement au sein du noyau, telles que le filtrage des paquets, la surveillance du trafic, l’application de la sécurité et même l’analyse des protocoles personnalisés.
    • Sa polyvalence et ses performances constituent l’un des principaux avantages de l’eBPF. En s’exécutant dans le noyau, les programmes eBPF peuvent accéder à et manipuler directement des paquets réseau, réduisant considérablement la surcharge par rapport aux méthodes traditionnelles de traitement des paquets d’espace utilisateur. Les programmes eBPF peuvent également être chargés dynamiquement et joints à différents crochets au sein du noyau, ce qui permet une réactivité et une adaptabilité en temps réel à la modification des conditions réseau.
    • La technologie eBPF est devenue de plus en plus populaire dans les applications de mise en réseau et de sécurité modernes en raison de sa flexibilité et de son efficacité. Elle est largement utilisée dans les outils et infrastructures pour la surveillance du réseau, la détection des intrusions, l’analyse du trafic et le réglage des performances. De plus, ses fonctionnalités s’étendent au-delà de la mise en réseau à d’autres domaines d’observabilité et de contrôle du système, ce qui en fait un composant fondamental pour un large éventail d’applications et de services Linux.

  • Azure Policy pour Kubernetes : pod qui étend le gatekeeper v3 open source et s’inscrit en tant que web-hook au contrôle d’admission Kubernetes, ce qui permet d’appliquer des mises en œuvre à grande échelle et des protections sur vos clusters de manière centralisée et cohérente. Le pod Azure Policy pour Kubernetes est déployé en tant que module complémentaire AKS. Elle est installée sur un seul nœud du cluster.

Diagramme montrant un exemple de l’architecture Azure Kubernetes Service.

Détails du composant Agent Defender

Nom du pod Espace de noms Genre Brève description Capabilities Limites des ressources Sortie requise
microsoft-defender-collector-ds-* kube-system DaemonSet Ensemble de conteneurs qui se concentrent sur la collecte d’événements d’inventaire et de sécurité à partir de l’environnement Kubernetes. SYS_ADMIN,
SYS_RESOURCE,
SYS_PTRACE		 mémoire : 296Mi

processeur : 360m		 Non
microsoft-defender-collector-misc-* kube-system Déploiement Ensemble de conteneurs qui se concentrent sur la collecte d’événements d’inventaire et de sécurité à partir de l’environnement Kubernetes qui ne sont pas limités à un nœud spécifique. N/A mémoire : 64Mi

Processeur : 60m		 Non
microsoft-defender-publisher-ds-* kube-system DaemonSet Publiez les données collectées dans le service principal de Microsoft Defender pour les conteneurs, où les données seront traitées et analysées. N/A mémoire : 200Mi

Processeur : 60m		 Https 443

Comment fonctionne la détection sans agent pour Kubernetes dans Azure ?

Le processus de découverte est basé sur des instantanés pris à intervalles réguliers :

Diagramme montrant un exemple de l’architecture des autorisations Kubernetes. Lorsque vous activez la détection sans agent pour l’extension Kubernetes, le processus suivant se produit :

  • Créer :

    • Si l’extension est activée à partir de Defender CSPM, Defender pour le cloud crée une identité dans les environnements clients appelée CloudPosture/securityOperator/DefenderCSPMSecurityOperator.
    • Si l’extension est activée à partir de Defender pour les conteneurs, Defender pour le cloud crée une identité dans les environnements clients appelée CloudPosture/securityOperator/DefenderForContainersSecurityOperator.
    • Attribuer : Defender pour le cloud attribue un rôle intégré appelé Opérateur sans agent Kubernetes à cette identité sur l’étendue d’abonnement. Le rôle contient les autorisations suivantes :
    • Lecture AKS (Microsoft.ContainerService/managedClusters/read)
    • Accès Approuvé AKS avec les autorisations suivantes :
    • Microsoft.ContainerService/managedClusters/trustedAccessRoleBindings/write
    • Microsoft.ContainerService/managedClusters/trustedAccessRoleBindings/read
    • Microsoft.ContainerService/managedClusters/trustedAccessRoleBindings/delete

  • Détection : à l’aide de l’identité affectée par le système, Defender pour le cloud procède à une détection des clusters AKS dans votre environnement par le biais d’appels d’API au serveur d’API d’AKS.

  • Liaison : Lors de la détection d’un cluster AKS, Defender pour le cloud effectue une opération de liaison AKS en créant un ClusterRoleBinding entre l’identité créée et l’opérateur Kubernetes ClusterRole aks:trustedaccessrole:defender-containers:microsoft-defender-operator. Le ClusterRole est visible via l’API et donne à Defender pour le cloud l’autorisation de lecture du plan de données à l’intérieur du cluster.

Obtenir un accès sécurisé pour les ressources Azure dans Azure Kubernetes Service en utilisant l’accès approuvé (préversion)

De nombreux services Azure qui s’intègrent dans Azure Kubernetes Service (AKS) doivent accéder au serveur d’API Kubernetes. Pour éviter d’octroyer à ces services un accès administrateur ou de rendre vos clusters AKS publics pour l’accès réseau, vous pouvez utiliser la fonctionnalité AKS Trusted Access.

Cette fonctionnalité offre aux services un accès sécurisé à AKS et Kubernetes à l’aide du back-end Azure sans nécessiter de point de terminaison privé. Au lieu de s’appuyer sur des identités avec des autorisations Microsoft Entra ID, cette fonctionnalité peut utiliser votre identité managée affectée par le système pour s’authentifier sur les services managés et les applications que vous voulez utiliser avec vos clusters AKS.

Important

Les fonctionnalités d’évaluation AKS sont disponibles en libre-service et font l’objet d’un abonnement. Les préversions sont fournies « en l’état » et « en fonction des disponibilités », et sont exclues des contrats de niveau de service et de la garantie limitée. Les préversions AKS sont, dans la mesure du possible, partiellement couvertes par le service clientèle.

Remarque

L’API Trusted Access est en disponibilité générale. Nous fournissons une prise en charge de la disponibilité générale (GA) pour Azure CLI, mais elle est toujours en préversion et nécessite l’utilisation de l’extension aks-preview.

Vue d’ensemble de la fonctionnalité Trusted Access

Trusted Access répond aux scénarios suivants :

  • Si une plage d’adresses IP autorisées est définie ou dans un cluster privé, les services Azure peuvent ne pas être en mesure d’accéder au serveur d’API Kubernetes, sauf si vous implémentez un modèle d’accès de point de terminaison privé.
  • Donner à un administrateur de service Azure l’accès à l’API Kubernetes ne suit pas la meilleure pratique d’accès aux privilèges minimum et peut entraîner des élévations de privilèges ou un risque de fuite d’informations d’identification. Par exemple, vous pourriez devoir implémenter des autorisations service-à-service à haut niveau de privilège, et elles ne sont pas idéales dans une revue d’audit.

Vous pouvez utiliser Trusted Access pour donner le consentement explicite à votre identité managée affectée par le système des ressources autorisées d’accéder à vos clusters AKS en utilisant une ressource Azure appelée liaison de rôles. Vos ressources Azure accèdent aux clusters AKS grâce à la passerelle régionale AKS via une authentification par identité managée affectée par le système. Les autorisations Kubernetes appropriées sont affectées via une ressource Azure appelée rôle. En utilisant Trusted Access, vous pouvez accéder aux clusters AKS avec différentes configurations, y compris, mais sans s’y limiter, les clusters privés, les clusters qui ont des comptes locaux désactivés, les clusters Microsoft Entra et les clusters de plage IP autorisée.

Prérequis

  • Compte Azure avec un abonnement actif. Créez un compte gratuitement.

  • Types de ressources prenant en charge l’identité managée affectée par le système.

    • Si vous utilisez Azure CLI, l’extension aks-preview 0.5.74 ou version ultérieure est requise.

  • Pour savoir quels rôles utiliser dans différents scénarios, consultez les articles suivants :

    • Accès Azure Machine Learning aux clusters AKS avec des configurations spéciales
    • Qu’est-ce que la sauvegarde Azure Kubernetes Service ?
    • Activer une posture de conteneur sans agent

Diagramme d’architecture de Defender pour le cloud et des clusters Kubernetes avec Arc

Les composants suivants sont requis afin de bénéficier de la protection totale offerte par Microsoft Defender pour les conteneurs.

  • Kubernetes avec Azure Arc – Kubernetes avec Azure Arc : une solution basée sur un agent, installée sur un nœud dans le cluster qui connecte vos clusters à Defender pour le cloud. Defender pour le cloud peut alors déployer les deux agents suivants comme extensions Arc :
  • Agent Defender : Le DaemonSet déployé sur chaque nœud qui collecte les signaux de l’hôte à l’aide de la technologie eBPF et des journaux d’audit Kubernetes pour assurer la protection du runtime. L’agent est inscrit auprès d’un espace de travail Log Analytics et utilisée comme un pipeline de données. Toutefois, les données du journal d’audit ne sont pas stockées dans l’espace de travail Log Analytics. L’agent Defender est déployé en tant qu’extension Kubernetes avec Arc.
  • Azure Policy pour Kubernetes : Pod qui étend le Gatekeeper v3 open source et s’inscrit en tant que webhook au contrôle d’admission Kubernetes, ce qui permet d’appliquer des mises en œuvre à grande échelle et de protéger vos clusters de manière centralisée et cohérente. Le pod Azure Policy pour Kubernetes est déployé en tant qu’extension Kubernetes avec Arc. L’installation est uniquement effectuée sur un nœud dans le cluster. Pour plus d’informations, consultez Protéger vos charges de travail Kubernetes et Comprendre Azure Policy pour les clusters Kubernetes.

Diagramme montrant un exemple de l’architecture dotée d’Azure Arc.

Diagramme d’architecture de Defender pour le cloud et des clusters EKS

Quand Defender pour le cloud protège un cluster hébergé dans Elastic Kubernetes Service, la collecte des données des journaux d’audit se fait sans agent. Il s’agit des composants nécessaires afin de bénéficier de la protection totale offerte par Microsoft Defender pour les conteneurs :

  • Journaux d’audit Kubernetes : le CloudWatch du compte AWS active et collecte les données du journal d’audit par le biais d’un collecteur sans agent, et envoie les informations collectées au back-end Microsoft Defender pour le cloud pour une analyse plus poussée.
  • Kubernetes avec Azure Arc – Kubernetes avec Azure Arc : une solution basée sur un agent, installée sur un nœud dans le cluster qui connecte vos clusters à Defender pour le cloud. Defender pour le cloud peut alors déployer les deux agents suivants comme extensions Arc :
  • Agent Defender : le DaemonSet déployé sur chaque nœud collecte des signaux des hôtes à l’aide de la technologie eBPF et offre une protection en temps d’exécution. L’agent est inscrit auprès d’un espace de travail Log Analytics et utilisée comme un pipeline de données. Toutefois, les données du journal d’audit ne sont pas stockées dans l’espace de travail Log Analytics. L’agent Defender est déployé en tant qu’extension Kubernetes avec Arc.
  • Azure Policy pour Kubernetes : Pod qui étend le Gatekeeper v3 open source et s’inscrit en tant que webhook au contrôle d’admission Kubernetes, ce qui permet d’appliquer des mises en œuvre à grande échelle et de protéger vos clusters de manière centralisée et cohérente. Le pod Azure Policy pour Kubernetes est déployé en tant qu’extension Kubernetes avec Arc. L’installation est uniquement effectuée sur un nœud dans le cluster.

Diagramme montrant un exemple de l’architecture Amazon Elastic Kubernetes Service. Comment fonctionne la détection sans agent pour Kubernetes dans AWS ?

Le processus de découverte est basé sur des instantanés pris à intervalles réguliers :

Lorsque vous activez l’extension Découverte sans agent pour Kubernetes, le processus suivant se produit :

  • Créer :

    • Le rôle Defender pour le cloud MDCContainersAgentlessDiscoveryK8sRole doit être ajouté à l’aws-auth ConfigMap des clusters EKS. Le nom peut être personnalisé.

  • Attribuer : Defender pour le Cloud attribue le rôle MDCContainersAgentlessDiscoveryK8sRole aux autorisations suivantes :

    • eks:UpdateClusterConfig
    • eks:DescribeCluster

  • Détection : à l’aide de l’identité affectée par le système, Defender pour le cloud procède à une détection des clusters EKS dans votre environnement par le biais d’appels d’API au serveur d’API d’EKS.

Diagramme d’architecture de Defender pour le cloud et des clusters GKE

Quand Defender pour le cloud protège un cluster hébergé dans Google Kubernetes Engine, la collecte des données des journaux d’audit se fait sans agent. Il s’agit des composants nécessaires afin de bénéficier de la protection totale offerte par Microsoft Defender pour les conteneurs :

  • Journaux d’audit Kubernetes : GCP Cloud Logging active et collecte les données du journal d’audit par le biais d’un collecteur sans agent, et envoie les informations collectées au back-end Microsoft Defender pour le cloud pour une analyse plus poussée.
  • Kubernetes avec Azure Arc – Kubernetes avec Azure Arc : une solution basée sur un agent, installée sur un nœud dans le cluster qui connecte vos clusters à Defender pour le cloud. Defender pour le cloud peut alors déployer les deux agents suivants comme extensions Arc :
  • Agent Defender : le DaemonSet déployé sur chaque nœud collecte des signaux des hôtes à l’aide de la technologie eBPF et offre une protection en temps d’exécution. L’agent est inscrit auprès d’un espace de travail Log Analytics et utilisée comme un pipeline de données. Toutefois, les données du journal d’audit ne sont pas stockées dans l’espace de travail Log Analytics. L’agent Defender est déployé en tant qu’extension Kubernetes avec Arc.
  • Azure Policy pour Kubernetes : Pod qui étend le Gatekeeper v3 open source et s’inscrit en tant que webhook au contrôle d’admission Kubernetes, ce qui permet d’appliquer des mises en œuvre à grande échelle et de protéger vos clusters de manière centralisée et cohérente. Le pod Azure Policy pour Kubernetes est déployé en tant qu’extension Kubernetes avec Arc. L’installation doit uniquement être effectuée sur un nœud dans le cluster.

Diagramme montrant un exemple de cluster d’architecture Google Kubernetes Engine.

Comment fonctionne la détection sans agent pour Kubernetes dans GCP ?

Le processus de découverte est basé sur des instantanés pris à intervalles réguliers :

Lorsque vous activez l’extension Découverte sans agent pour Kubernetes, le processus suivant se produit :

  • Créer :

    • Le compte de service mdc-containers-k8s-operator est créé. Le nom peut être personnalisé.

  • Attribuer : Defender pour le cloud attache les rôles suivants au compte de service mdc-containers-k8s-operator :

    • le rôle personnalisé MDCGkeClusterWriteRole, qui a l’autorisation container.clusters.update
    • le rôle intégré container.viewer

  • Détection : à l’aide de l’identité affectée par le système, Defender pour le cloud procède à une détection des clusters GKE dans votre environnement par le biais d’appels d’API au serveur d’API de GKE.