Sécurité pour AKS

  • Article

Cet article vous explique les aspects de la gouvernance de la sécurité AKS (Azure Kubernetes Service) à prendre en considération avant d’implémenter une solution.

L’article traite essentiellement de l’implémentation de solutions en utilisant Azure et des logiciels open source. Les décisions que vous prenez au moment de créer une zone d’atterrissage à l’échelle de l’entreprise peuvent partiellement prédéfinir votre gouvernance. Pour comprendre les principes de gouvernance, consultez Sécurité, gouvernance et conformité à l’échelle de l’entreprise.

Surfaces d’attaque

Tenez compte des cinq surfaces d’attaque suivantes au moment de créer une stratégie de sécurité pour des clusters Kubernetes :

  • Build
  • Registre
  • Cluster
  • Nœud
  • Application

Pour chaque catégorie, nous évoquerons les risques majeurs à prendre en considération ainsi que les contre-mesures pour gérer ces risques.

Intégrer la sécurité

La sécurité des builds concerne la bonne utilisation de DevSecOps avec les images conteneur.

Risques majeurs

Une mauvaise configuration de l’image peut engendrer des failles de sécurité en aval. Par exemple, il est possible que vous disposiez de conteneurs qui s’exécutent avec des privilèges plus importants que nécessaire. Les conteneurs peuvent également être configurés pour autoriser certains accès réseau, ce qui peut mettre le système en danger. En ne limitant pas les appels système autorisés aux appels nécessaires au fonctionnement sûr des conteneurs, vous pouvez accroître les risques liés à un conteneur compromis.

Une autre vulnérabilité pourrait être de permettre au conteneur d’accéder à un répertoire sensible de l’hôte ou d’autoriser les conteneurs à modifier les emplacements qui contrôlent la fonction de base de l’hôte.

Les conteneurs non autorisés sont des conteneurs non planifiés dans un environnement. Ils peuvent être le résultat du test de leur code effectué par des développeurs dans des environnements de test. Il est possible que ces conteneurs n’aient pas fait l’objet d’une recherche de vulnérabilités rigoureuse ou qu’ils ne soient pas correctement configurés. Ces vulnérabilités peuvent ouvrir un point d’entrée aux attaquants.

L’utilisation d’images de base qui ne proviennent pas de sources approuvées ou dont les correctifs de sécurité ne sont pas à jour peut également engendrer des failles dans les conteneurs qu’elles utilisent pour la génération.

Contre-mesures aux risques

La sécurité des builds concerne l’implémentation de DevSecOps pour déplacer la sécurité vers la gauche et corriger la plupart des problèmes avant qu’ils ne commencent à descendre dans le pipeline. Il ne s’agit pas de faire porter toute la responsabilité aux développeurs, mais de la partager avec les opérations. Les développeurs peuvent alors voir et corriger les vulnérabilités et les problèmes de conformité qu’ils peuvent réellement résoudre.

Vous pouvez créer un pipeline qui analyse et fait échouer les builds, car il a une ou 10 vulnérabilités critiques. Une meilleure approche peut consister à examiner la couche située juste en dessous. Vous pouvez commencer à segmenter le point de responsabilité en fonction de l’état du fournisseur.

Définissez un seuil au niveau de la couche état de la vulnérabilité. Toute vulnérabilité présentant l’état Ouvert, Ne sera pas corrigé ou Différé poursuit sa progression dans le pipeline où les opérateurs de sécurité peuvent évaluer le risque, comme ils le font aujourd’hui. Une vulnérabilité dont l’état est Correctifs fournisseur disponibles peut être traitée par un développeur. L’utilisation de périodes de grâce laisse aux développeurs le temps de remédier aux failles.

L’évaluation des vulnérabilités est accompagnée d’une évaluation de la conformité. Par exemple, le fait d’autoriser une image à s’exécuter en tant que racine ou à exposer SSH est en contradiction avec la posture de conformité de la plupart des entreprises. Corrigez ce problème pendant la phase de génération plutôt que pendant la phase de déploiement.

En règle générale, vous analysez vos images par rapport au point de référence Docker CIS. Lorsque vous utilisez ces types de flux, vous n’interrompez pas le développement en introduisant une correction de sécurité, mais vous pouvez améliorer la posture de sécurité globale de votre entreprise.

L’utilisation d’un outil qui offre ces capacités est essentielle pour mettre en œuvre efficacement la bonne stratégie pour votre entreprise. Les outils traditionnels sont souvent incapables de détecter les vulnérabilités dans les conteneurs, ce qui peut donner un faux sentiment de sécurité. Des outils qui prennent en considération l’approche de génération basée sur le pipeline et la nature immuable et déclarative des technologies de conteneurs s’avèrent nécessaires pour sécuriser correctement votre écosystème de conteneurs.

Ces outils doivent avoir les propriétés suivantes :

  • Intégration à toute la durée de vie des images, du début du processus de génération jusqu’à l’exécution, en passant par le registre.
  • Ils doivent avoir une visibilité des vulnérabilités dans toutes les couches de l’image, y compris la couche de base de l’image, les infrastructures d’application et les logiciels personnalisés.
  • Mise en application basée sur des stratégies avec le niveau de granularité approprié, ce qui permet à votre organisation de créer des barrières de qualité à chaque étape des processus de génération et de déploiement.

Sécurité des registres

La sécurité des registres concerne :

  • le contrôle de la dérive par rapport à la génération ;
  • la prévention de l’envoi (push) ou du tirage (pull) d’images contaminées ;
  • la signature des images.

Risques majeurs

Les images contiennent souvent des informations propriétaires, notamment le code source d’une organisation. Si les connexions aux registres ne sont pas correctement sécurisées, le contenu d’une image peut présenter des risques de confidentialité aussi importants que toute autre forme de transmission de données au sein de votre organisation. Les images périmées présentant des versions obsolètes vulnérables dans le registre peuvent accroître les risques de sécurité si elles sont déployées accidentellement.

Une autre faille de sécurité peut être l’insuffisance des restrictions d’authentification et d’autorisation pour les registres de conteneurs. Ces registres peuvent contenir des ressources propriétaires sensibles dans les images.

À mesure que du contenu est créé et déployé, sa distribution devient l’un des nombreux vecteurs d’attaque. Comment s’assurer que le contenu préparé pour la distribution est le même que celui qui est remis au point de terminaison prévu ?

Contre-mesures aux risques

Configurez des processus de déploiement de sorte que les outils de développement, les réseaux et les runtimes de conteneurs soient connectés aux registres uniquement via des canaux chiffrés. De même, veillez à ce que le contenu provienne d’une source de confiance. Pour réduire les risques liés à l’utilisation d’images périmées :

  • Supprimez des registres de conteneurs les images vulnérables et potentiellement dangereuses qui ne doivent plus être utilisées.
  • Imposez un accès aux images avec des noms immuables qui spécifient les versions précises des images à utiliser. Vous pouvez mettre en œuvre cette configuration en utilisant une étiquette latest (le plus récent) ou une version spécifique des images. Une balise ne garantit pas l’actualisation. À cette fin, mettez en place un processus pour faire en sorte que l’orchestrateur Kubernetes utilise les numéros uniques les plus récents ou que l’étiquette latest représente les versions les plus récentes.

L’accès aux registres contenant des images sensibles doit imposer une authentification et une autorisation. Tout accès en écriture doit également nécessiter une authentification. Par exemple, votre stratégie peut autoriser les développeurs à envoyer (push) uniquement des images aux référentiels spécifiques dont ils sont responsables.

L’accès à ces registres doit être fédéré et tirer parti des stratégies d’accès au niveau du secteur d’activité. Par exemple, vous pouvez configurer votre pipeline CI/CD de sorte que les images soient envoyées (push) aux référentiels uniquement après avoir passé avec succès l’évaluation de conformité et les tests de contrôle de qualité relatifs à l’analyse des vulnérabilités.

Les registres de conteneurs, désormais considérés comme des registres d’artefacts, deviennent l’un des principaux moyens de déployer tout type de contenu, et pas seulement des images conteneur. Chaque cloud fournit un registre avec des projets open source et des produits de fournisseurs disponibles pour un hébergement local ou privé auprès du fournisseur de services cloud. Le contenu est promu au sein des registres et entre eux, de sa génération initiale à son déploiement en production.

Comment s’assurer que le contenu qui est entré dans le registre présente la même intégrité que le contenu qui en sort ? En adoptant une solution de signature d’image, vous avez l’assurance que les déploiements proviennent uniquement de registres de confiance et qu’ils déploient du contenu faible.

Sécurité des clusters

La sécurité des clusters concerne :

  • Authentification et autorisation.
  • Sécurité réseau.
  • Gestion des vulnérabilités et de la conformité.

Risques majeurs

Parfois, un seul cluster Kubernetes peut être utilisé pour exécuter différentes applications gérées par différentes équipes avec des exigences de niveau d’accès différentes. Si l’accès est fourni à des personnes sans restrictions ou uniquement en fonction de leurs besoins, un utilisateur malveillant ou négligent peut compromettre les charges de travail auxquelles il devrait avoir accès et d’autres ressources sur le cluster.

Une autre faille de sécurité peut se présenter lorsque l’annuaire d’utilisateurs du cluster gère lui-même l’autorisation et l’authentification. Un annuaire d’authentification d’organisation est souvent contrôlé de façon plus rigoureuse. Sachant que ces comptes disposent de privilèges élevés et qu’ils sont plus souvent orphelins, ils sont davantage exposés à des risques de compromission.

Ce scénario peut engendrer des failles de cluster ou même à l’échelle du système. Les données stockées par des volumes de conteneur sont gérées par des orchestrateurs, qui doivent avoir accès aux données, quel que soit le nœud sur lequel elles sont hébergées.

Les filtres réseau traditionnels peuvent faire preuve de cécité en matière de sécurité en raison d’une surcouche réseau conçue pour chiffrer les données en transit. Cette conception rend difficile le monitoring du trafic au sein du cluster. Des dispositions particulières peuvent donc être nécessaires pour analyser les clusters Kubernetes.

Le trafic en provenance de différentes applications partageant un même cluster peut présenter des niveaux de sensibilité différents. Tel est le cas d’un site web accessible au public et d’une application interne exécutant des processus métier sensibles et critiques. Le partage du même réseau virtuel au sein du cluster peut entraîner un risque de compromission des données sensibles. Par exemple, un attaquant peut utiliser le réseau partagé exposé à Internet pour attaquer les applications internes.

Protégez les composants qui exécutent le cluster lui-même contre les vulnérabilités et les problèmes de conformité. Vérifiez que vous exécutez la dernière version possible de Kubernetes pour bénéficier de la correction.

Contre-mesures aux risques

L’accès des utilisateurs au cluster Kubernetes doit utiliser un modèle d’accès avec des privilèges minimum. N’accordez aux utilisateurs que l’accès nécessaire à l’exécution d’actions spécifiques sur des hôtes, conteneurs et images spécifiques pour leur permettre de faire leur travail. Les membres de l’équipe de test doivent avoir un accès limité ou inexistant aux conteneurs en production. Les comptes d’utilisateurs disposant d’un accès à l’échelle du cluster doivent être étroitement contrôlés et être utilisés avec parcimonie.

Utilisez des méthodes d’authentification forte comme l’authentification multifacteur pour sécuriser l’accès à ces comptes. Un annuaire d’utilisateurs d’organisation doit être utilisé pour gérer des clusters via l’authentification unique, contrairement aux comptes d’utilisateurs spécifiques d’un cluster, qui peuvent ne pas avoir le même niveau de stratégies et de contrôles.

Utilisez des méthodes de chiffrement qui permettent aux conteneurs d’accéder correctement aux données, quel que soit l’hôte sur lequel ces conteneurs s’exécutent. Ces outils de chiffrement doivent empêcher tout accès non autorisé aux données par d’autres conteneurs, même au sein d’un même nœud, qui ne devraient pas y avoir accès.

Configurez les clusters Kubernetes de façon à séparer le trafic réseau en réseaux ou sous-réseaux virtuels distincts par niveau de sensibilité. Une segmentation par application est également envisageable, mais la simple définition de réseaux par niveaux de sensibilité peut suffire. Par exemple, il convient au minimum de mettre en place des réseaux virtuels distincts pour les applications destinées aux clients et pour les applications internes dont le trafic est sensible.

Vous pouvez utiliser des teintes et des tolérances pour isoler des déploiements sur des ensembles spécifiques de nœuds par niveaux de sensibilité. Évitez d’héberger des charges de travail hautement sensibles dans le même nœud que des charges de travail de moindre sensibilité. L’utilisation de clusters managés distincts est une option plus sûre.

Segmentez les conteneurs par usage, sensibilité et posture de threads pour assurer une protection supplémentaire pour les charges de travail sensibles. En segmentant les conteneurs de cette manière, il est plus difficile pour un attaquant qui a réussi à accéder à un segment d’accéder à d’autres segments. Cette configuration présente également l’avantage de garantir que les données résiduelles, telles que les caches ou les montages de volumes, sont isolées par niveau de sensibilité.

Les clusters Kubernetes doivent être configurés de la façon suivante :

  • Fournir un environnement sécurisé pour les applications qui s’y exécutent.
  • S’assurer que les nœuds sont ajoutés de façon sécurisée au cluster.
  • Disposer d’identités persistantes pour garantir la sécurité tout au long de leur cycle de vie.
  • Fournir des informations en direct et précises sur l’état du cluster, y compris la mise en réseau et les nœuds qu’il contient.

Un nœud compromis doit être facile à isoler et à supprimer du cluster sans affecter les performances de ce dernier. AKS rend cela simple.

Définissez des standards de configuration de runtime de conteneur pour garantir automatiquement la conformité. Il existe diverses stratégies dans Azure qui facilitent ce processus, et les utilisateurs peuvent aussi créer leurs propres stratégies. Utilisez les fonctionnalités de sécurité d’Azure pour évaluer en permanence les paramètres de configuration dans l’ensemble de l’environnement et les appliquer activement.

Ayez automatiquement l’assurance que les vulnérabilités des composants Kubernetes sont traitées. Utilisez des environnements distincts pour le développement, les tests et la production, chacun avec ses propres contrôles et son contrôle d’accès en fonction du rôle (RBAC) pour la gestion des conteneurs. Associez toute la création de conteneurs à des identités d’utilisateur individuelles et journalisez-la à des fins d’audit. Cette configuration réduit le risque de disposer de conteneurs non autorisés.

Sécurité des nœuds

La sécurité des nœuds concerne :

  • la protection du runtime ;
  • Gestion des vulnérabilités et de la conformité.

Risques majeurs

Un nœud Worker dispose d’un accès privilégié à tous les composants du nœud. Les attaquants peuvent utiliser comme point d’entrée n’importe quel service accessible via le réseau. Ainsi, le fait de fournir un accès à l’hôte depuis plusieurs points peut sérieusement accroître sa surface d’attaque. Plus la surface d’attaque est grande, plus un attaquant a de chances d’accéder au nœud et à son système d’exploitation.

En outre, les systèmes d’exploitation propres aux conteneurs, comme ceux utilisés dans les nœuds AKS, ont une surface d’attaque plus réduite car ils ne contiennent pas les bibliothèques qui permettent aux systèmes d’exploitation ordinaires d’exécuter directement des bases de données et des serveurs web. L’utilisation d’un noyau partagé a pour effet d’agrandir la surface d’attaque pour les conteneurs s’exécutant dans le même environnement que les conteneurs situés sur des machines virtuelles distinctes. C’est le cas même lorsque des systèmes d’exploitation propres aux conteneurs s’exécutant sur des nœuds AKS sont utilisés.

Les systèmes d’exploitation hôtes fournissent des composants système fondamentaux qui peuvent présenter des vulnérabilités et des risques de conformité. S’agissant de composants de bas niveau, leurs vulnérabilités et leur configuration peuvent affecter tous les conteneurs hébergés. AKS protège les utilisateurs en faisant en sorte que ces vulnérabilités soient corrigées par des mises à jour régulières du système d’exploitation sur les nœuds qui s’exécutent sur AKS et que la posture de conformité du nœud Worker soit maintenue.

Des droits d’accès utilisateur incorrects peuvent également une source de risques pour la sécurité lorsque les utilisateurs se connectent directement aux nœuds pour gérer les conteneurs au lieu de passer par le plan de contrôle d’AKS. La connexion directe peut permettre à l’utilisateur d’apporter des modifications à des applications au-delà de celles auxquelles il doit avoir accès.

En outre, les conteneurs malveillants peuvent entraîner la falsification du système de fichiers du système d’exploitation hôte. Par exemple, si un conteneur est autorisé à monter un répertoire sensible dans le système d’exploitation hôte, ce conteneur peut apporter des modifications aux fichiers. Les modifications peuvent nuire à la sécurité des autres conteneurs s’exécutant sur l’hôte.

Contre-mesures aux risques

Restreignez l’accès au nœud en limitant l’accès SSH.

L’utilisation du système d’exploitation propre aux conteneurs dans les nœuds AKS a généralement pour effet de réduire les surfaces d’attaque, car les autres services et fonctionnalités sont désactivés. Ils disposent également de systèmes de fichiers en lecture seule et utilisent par défaut d’autres pratiques de renforcement de la sécurité des clusters.

La plateforme Azure applique automatiquement les correctifs de sécurité du système d’exploitation aux nœuds Linux et Windows chaque nuit. Si une mise à jour de la sécurité du système d’exploitation Linux nécessite un redémarrage de l’hôte, ce redémarrage n’est pas effectué automatiquement. AKS fournit des mécanismes de redémarrage pour appliquer ces correctifs spécifiques.

Microsoft Defender pour serveurs ne s’applique pas aux nœuds AKS Linux et Windows, car Microsoft gère leur système d’exploitation. S’il n’y a pas d’autres machines virtuelles dans l’abonnement où est déployé AKS, vous pouvez désactiver de manière sécurisée Microsoft Defender pour serveurs.

Si l’environnement a été déployé, y compris les stratégies Azure recommandées de zone d’atterrissage à l’échelle de l’entreprise, vous pouvez configurer une exclusion pour l’affectation de stratégie dans le groupe d’administration qui active automatiquement Microsoft Defender pour serveurs de façon à éviter des coûts inutiles.

Sécurité des applications

La sécurité des applications concerne :

  • la protection du runtime ;
  • Gestion des vulnérabilités et de la conformité.

Risques majeurs

Les images sont des fichiers qui comprennent tous les composants nécessaires à l’exécution d’une application. Lorsque la dernière version de ces composants est utilisée pour créer les images, celles-ci peuvent être exemptes de vulnérabilités connues à ce moment-là, mais cela peut changer rapidement.

Vous devez tenir à jour ces fichiers avec les dernières versions, car les développeurs de packages identifient régulièrement des failles de sécurité. Effectuez les mises à jour des conteneurs plus en amont en mettant à jour les images utilisées pour créer les conteneurs, contrairement aux applications traditionnelles, qui sont généralement mises à jour au niveau de l’hôte.

Des fichiers malveillants peuvent également être incorporés dans une image, qui peut ensuite être utilisée pour attaquer d’autres conteneurs ou composants du système. Les conteneurs tiers peuvent être un vecteur d’attaque. Certains détails les concernant peuvent être inconnus et ils peuvent faire fuiter des données. Les conteneurs n’ont peut-être pas été tenus à jour avec les mises à jour de sécurité nécessaires.

Un autre vecteur d’attaque est l’utilisation de l’incorporation de secrets comme des mots de passe et des chaînes de connexion directement dans le système de fichiers image. Cette pratique peut présenter un risque pour la sécurité, car toute personne ayant accès à l’image peut avoir accès aux secrets.

Il peut y avoir des failles dans les applications elles-mêmes, par exemple des applications vulnérables au scripting inter-site ou à l’injection de code SQL. Lorsque des failles existent, la vulnérabilité peut être utilisée pour permettre un accès non autorisé à des informations sensibles dans d’autres conteneurs ou même dans le système d’exploitation hôte.

Le runtime de conteneurs AKS facilite la recherche de vulnérabilités avec les différents outils de sécurité disponibles sur Azure. Pour plus d’informations, consultez Présentation de Microsoft Defender pour Kubernetes.

Vous devez également contrôler le trafic réseau sortant envoyé à des conteneurs pour empêcher ceux-ci de diriger le trafic vers des réseaux de différents niveaux de sensibilité, comme des environnements hébergeant des données sécurisées, ou vers Internet. Azure facilite ce contrôle grâce à ses diverses fonctionnalités de sécurité réseau et AKS.

Par défaut, les planificateurs Kubernetes se concentrent sur la mise à l’échelle et l’optimisation de la densité des charges de travail exécutées sur les nœuds. Ils risquent de placer des pods de différents niveaux de sensibilité dans le même nœud, simplement parce qu’il s’agit de l’hôte ayant le plus de ressources disponibles. Ce scénario peut potentiellement déboucher sur des incidents de sécurité lorsque des attaquants se servent de l’accès à des charges de travail publiques pour attaquer des conteneurs exécutant des processus plus sensibles sur le même hôte. Un conteneur compromis peut également être utilisé pour analyser le réseau afin de trouver d’autres vulnérabilités que l’attaquant peut exploiter.

Contre-mesures aux risques

Ne stockez jamais les secrets dans le code d’application ou les systèmes de fichiers. Les secrets doivent être stockés dans des magasins de clés et fournis aux conteneurs au moment de l’exécution, selon les besoins. AKS peut s’assurer que seuls les conteneurs qui ont besoin d’accéder à certaines clés y ont accès et que ces secrets ne sont pas conservés sur le disque. Par exemple, Azure Key Vault peut stocker ces secrets en toute sécurité et les fournir au cluster AKS selon les besoins. Il est également facile de s’assurer que ces secrets sont chiffrés à la fois dans le stockage et en transit.

Évitez d’utiliser des registres et des images non fiables et veillez à ce que seules les images issues de jeux approuvés soient autorisées à s’exécuter dans leurs clusters. Pour une approche multicouche :

  • Contrôler de manière centralisée quelles images et quels registres sont fiables.
  • Identifier discrètement chaque image par une signature de chiffrement.
  • Mettre en place des stratégies qui garantissent que tous les hôtes exécutent uniquement des images provenant du jeu approuvé.
  • Valider ces signatures avant l’exécution.
  • Surveiller et mettre à jour ces images et ces registres à mesure que les vulnérabilités et les exigences de configuration évoluent.

Des profils informatiques sécurisés doivent être utilisés pour contraindre les conteneurs et être alloués au moment de l’exécution. Des profils personnalisés peuvent être créés et transmis aux runtimes de conteneurs pour limiter davantage leurs capacités. Au minimum, vérifiez que les conteneurs sont exécutés avec les profils par défaut. Envisagez d’utiliser des profils personnalisés et plus restreints pour les conteneurs exécutant des applications à haut risque.

Des outils peuvent profiler automatiquement les applications en utilisant l’apprentissage comportemental et détecter les anomalies. Vous pouvez utiliser des solutions tierces pour détecter les anomalies au moment de l’exécution. Ces anomalies peuvent correspondre aux événements suivants :

  • Exécution de processus ou appels système non valides ou inattendus.
  • Modifications apportées aux fichiers de configuration et à des binaires protégés.
  • Écritures dans des emplacements et des types de fichiers inattendus.
  • Création d’écouteurs réseau inattendus.
  • Envoi de trafic vers des destinations réseau inattendues.
  • Stockage et exécution de programmes malveillants.

Microsoft Defender pour Kubernetes investit actuellement dans ce domaine.

Les conteneurs doivent s’exécuter avec leur système de fichiers racine en mode lecture seule pour isoler les écritures dans des répertoires définis, que ces outils peuvent facilement surveiller. Cette configuration rend les conteneurs plus résilients en cas de compromission, car vous isolez la falsification à ces emplacements spécifiques. Ils peuvent facilement être séparés du reste de l’application.

Remarques relatives à la conception

AKS propose plusieurs interfaces avec d’autres services Azure comme Microsoft Entra ID, Stockage Azure et Réseau virtuel Microsoft Azure. L’utilisation de ces services demande une attention particulière lors de la phase de planification. AKS ajoute aussi une complexité supplémentaire qui vous oblige à appliquer les mêmes contrôles et mécanismes de gouvernance et de conformité en matière de sécurité que dans le reste du paysage de votre infrastructure.

Voici d’autres points de conception pour la gouvernance et la conformité de la sécurité AKS :

  • Si vous créez un cluster AKS dans un abonnement déployé selon les bonnes pratiques de zone d’atterrissage à l’échelle de l’entreprise, familiarisez-vous avec les stratégies Azure dont les clusters hériteront. Pour plus d’informations, consultez Stratégie incluses dans les implémentations des informations de référence sur les zones d’atterrissage Azure.
  • Décidez si le plan de contrôle du cluster doit être accessible via Internet (nous recommandons des restrictions IP), ce qui est le cas par défaut, ou uniquement depuis votre réseau privé dans Azure ou localement en tant que cluster privé. Si votre organisation suit les bonnes pratiques de zone d’atterrissage à l’échelle de l’entreprise, le groupe d’administration Corp est associé à une stratégie Azure Policy qui force les clusters à être privés. Pour plus d’informations, consultez Stratégie incluses dans les implémentations des informations de référence sur les zones d’atterrissage Azure.
  • Evaluez l’utilisation du module de sécurité Linux AppArmor intégré pour limiter les actions que les conteneurs peuvent effectuer, comme les opérations de lecture, d’écriture ou d’exécution ou les fonctions système comme le montage de systèmes de fichiers. Par exemple, l’ensemble des abonnements disposent de stratégies Azure qui empêchent les pods de tous les clusters AKS de créer des conteneurs privilégiés. Pour plus d’informations, consultez Stratégie incluses dans les implémentations des informations de référence sur les zones d’atterrissage Azure.
  • Évaluez l’utilisation de seccomp (secure computing) au niveau du processus pour limiter les appels de processus que les conteneurs peuvent effectuer. Par exemple, Azure Policy appliqué dans le cadre de l’implémentation de la zone d’atterrissage générique à l’échelle de l’entreprise dans le groupe de gestion des zones d’atterrissage pour empêcher l’élévation des privilèges des conteneurs vers la racine utilise seccomp via des stratégies Azure pour Kubernetes.
  • Décidez si votre registre de conteneurs est accessible via Internet ou seulement au sein d’un réseau virtuel spécifique. La désactivation de l’accès à Internet dans un registre de conteneurs peut avoir des effets négatifs sur les autres systèmes qui dépendent de la connectivité publique pour y accéder. Tel est le cas, par exemple, des pipelines d’intégration continue ou Microsoft Defender pour l’analyse d’images. Pour plus d’informations, consultez Connexion privée à un registre de conteneurs à l’aide d’Azure Private Link.
  • Décidez si votre registre de conteneurs privé est partagé entre plusieurs zones d’atterrissage ou si vous déployez un registre de conteneurs dédié dans chaque abonnement de zone d’atterrissage.
  • Envisagez d’utiliser une solution de sécurité comme Microsoft Defender pour Kubernetes pour la détection des menaces.
  • Envisagez d’analyser vos images conteneur pour détecter les vulnérabilités.
  • Envisagez de désactiver Microsoft Defender pour serveurs dans l’abonnement AKS s’il n’y a pas de machines virtuelles non AKS de façon à éviter des coûts inutiles.

Recommandations de conception

Important

L’analyse d’images Microsoft Defender pour le cloud n’est pas compatible avec les points de terminaison Container Registry. Pour plus d’informations, consultez Connexion privée à un registre de conteneurs à l’aide de Private Link.