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.
Notes
La prise en charge par Defender pour les conteneurs des clusters Kubernetes avec Arc (AWS EKS et GCP GKE) est une fonctionnalité en préversion.
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
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 :
Capteur Defender : DaemonSet déployé sur chaque nœud qui collecte les signaux des hôtes à l’aide de la technologie eBPF et fournit une protection du runtime. Le capteur est inscrit auprès d’un espace de travail Log Analytics et utilisé 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. Le capteur Defender est déployé en tant que profil de sécurité AKS.
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. 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.
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.
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 :
Lorsque vous activez l’extension Découverte sans agent pour Kubernetes, le processus suivant se produit :
Créer :
Si l’extension est activée à partir de la gestion de la posture de sécurité cloud (CSPM) Defender, 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 la portée d’un abonnement. Le rôle contient les autorisations suivantes :
Lecture AKS (Microsoft.ContainerService/managedClusters/read)
Accès approuvé AKS avec les autorisations suivantes :
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.
Lier : quand un cluster AKS est découvert, Defender pour le cloud effectue une opération de liaison AKS en créant un ClusterRoleBinding entre l’identité créée et le ClusterRoleaks:trustedaccessrole:defender-containers:microsoft-defender-operator Kubernetes. Le ClusterRole est visible via l’API, et accorde l’autorisation de lecture du plan de données à Defender pour le cloud à l’intérieur du cluster.
Remarque
L’instantané copié reste dans la même région que le cluster.
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 capteur, installé 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 :
Capteur Defender : DaemonSet déployé sur chaque nœud qui collecte les signaux des hôtes à l’aide de la technologie eBPF et des journaux d’audit Kubernetes, afin de fournir une protection du runtime. Le capteur est inscrit auprès d’un espace de travail Log Analytics et utilisé 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. Le capteur 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 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. 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.
Remarque
La prise en charge par Defender pour les conteneurs des clusters Kubernetes avec Arc est une fonctionnalité en préversion.
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 capteur, installé 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 :
Capteur Defender : DaemonSet déployé sur chaque nœud qui collecte les signaux des hôtes à l’aide de la technologie eBPF et fournit une protection du runtime. Le capteur est inscrit auprès d’un espace de travail Log Analytics et utilisé 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. Le capteur 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 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 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.
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é.
Attribution : 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.
Remarque
L’instantané copié reste dans la même région que le cluster.
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 capteur, installé sur un nœud dans le cluster qui active vos clusters pour les connecter à Defender pour le cloud. Defender pour le cloud peut alors déployer les deux agents suivants comme extensions Arc :
Capteur Defender : DaemonSet déployé sur chaque nœud qui collecte les signaux des hôtes à l’aide de la technologie eBPF et fournit une protection du runtime. Le capteur est inscrit auprès d’un espace de travail Log Analytics et utilisé 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.
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 qu’extension Kubernetes avec Arc. L’installation doit uniquement être 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.
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é.
Affectation : Defender pour le Cloud attache les rôles suivants au compte de service mdc-containers-k8s-operator :
Rôle MDCGkeClusterWriteRole personnalisé, qui dispose de l’autorisation container.clusters.update
Rôle container.viewer intégré
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.
Remarque
L’instantané copié reste dans la même région que le cluster.
Étapes suivantes
Dans cette présentation, vous avez découvert l’architecture de la sécurité des conteneurs dans Microsoft Defender pour le cloud. Pour activer le plan, consultez :
