Sécuriser les conteneurs Windows

S’applique à : Windows Server 2025, Windows Server 2022, Windows Server 2019, Windows Server 2016

La taille réduite des images des conteneurs s'explique par le fait qu'ils peuvent compter sur l'hôte pour fournir un accès limité à diverses ressources. Si le conteneur sait que l’hôte sera en mesure de fournir les fonctionnalités nécessaires pour effectuer un ensemble spécifique d’actions, le conteneur n’a pas besoin d’inclure le logiciel approprié dans son image de base. Toutefois, l’étendue du partage de ressources qui se produit peut avoir un impact significatif sur les performances et la sécurité du conteneur. Si trop de ressources sont partagées, l’application peut également s’exécuter en tant que processus sur l’hôte. Si les ressources sont partagées trop peu, le conteneur devient indistinguishable à partir d’une machine virtuelle. Les deux configurations s’appliquent à de nombreux scénarios, mais la plupart des utilisateurs utilisant des conteneurs optent généralement pour quelque chose au milieu.

La sécurité d’un conteneur Windows est dérivée du degré de partage qui se produit avec son hôte. La limite de sécurité d’un conteneur est constituée par les mécanismes d’isolation qui séparent le conteneur de l’hôte. Plus important encore, ces mécanismes d’isolation définissent les processus du conteneur qui peuvent interagir avec l’hôte. Si la conception d’un conteneur permet à un processus avec élévation de privilèges (administrateur) d’interagir avec l’hôte, Microsoft ne considère pas ce conteneur comme ayant une limite de sécurité robuste.

Conteneurs Windows Server et conteneurs Linux

Les conteneurs Windows Server isolés par processus et les conteneurs Linux partagent des degrés d’isolation similaires. Pour les deux types de conteneurs, le développeur doit supposer toute attaque pouvant être effectuée via un processus avec élévation de privilèges sur l’hôte peut également être effectuée via un processus avec élévation de privilèges dans le conteneur. Les deux fonctionnent via les fonctionnalités primitives offertes par leurs noyaux hôtes respectifs. Les images conteneur sont générées contenant des fichiers binaires en mode utilisateur qui utilisent les API fournies par le noyau hôte. Le noyau hôte fournit les mêmes fonctionnalités d’isolation et de gestion des ressources à chaque conteneur s’exécutant dans l’espace utilisateur. Si le noyau est compromis, alors tous les conteneurs partageant ce noyau le sont aussi.

La conception fondamentale des conteneurs Linux et Windows Server échange la sécurité en matière de flexibilité. Les conteneurs Windows Server et Linux sont basés sur les composants primitifs fournis par le système d’exploitation. Cela permet de partager des ressources et des espaces de noms entre des conteneurs, mais il ajoute une complexité supplémentaire qui ouvre la porte à l’exploitation. De manière générale, nous ne considérons pas le noyau comme une barrière de sécurité suffisante pour les charges de travail multilocataires hostiles.

Isolation du noyau à l'aide de conteneurs isolés par hyperviseur

Les conteneurs isolés par hyperviseur offrent un degré d’isolation plus élevé que les conteneurs Windows Server ou Linux isolés par processus et sont considérés comme des limites de sécurité robustes. Les conteneurs isolés par hyperviseur se composent d’un conteneur Windows Server encapsulé dans une machine virtuelle ultralight, puis s’exécutent en même temps que le système d’exploitation hôte via l’hyperviseur de Microsoft. L’hyperviseur fournit une isolation au niveau du matériel qui inclut une limite de sécurité hautement robuste entre l’hôte et d’autres conteneurs. Même si une attaque devait échapper au conteneur Windows Server, elle serait contenue dans la machine virtuelle isolée par hyperviseur.

Ni les conteneurs Windows Server ni les conteneurs Linux fournissent ce que Microsoft considère comme une limite de sécurité robuste et ne doivent pas être utilisés dans des scénarios multilocataires hostiles. Un conteneur doit être limité à une machine virtuelle dédiée pour empêcher un processus de conteneur non autorisé d’interagir avec l’hôte ou d’autres locataires. L’isolation de l’hyperviseur permet ce degré de séparation tout en offrant plusieurs gains de performances sur les machines virtuelles traditionnelles. Par conséquent, il est vivement recommandé que dans les scénarios multilocataires hostiles, les conteneurs isolés par hyperviseur soient le conteneur de choix.

Critères de maintenance de la sécurité des conteneurs

Microsoft s’engage à corriger toutes les attaques et échappements qui interrompent la limite d’isolation établie de n’importe quel type de conteneur Windows. Toutefois, seules les attaques qui interrompent une limite de sécurité sont traitées via le processus MSRC (Microsoft Security Response Center). Seuls les conteneurs isolés par hyperviseur fournissent une limite de sécurité et les conteneurs isolés par processus ne le font pas. La seule façon de générer un bogue pour un échappement de conteneur isolé au niveau du processus, c'est si un processus non administrateur parvient à accéder à l’hôte. Si une attaque utilise un processus d’administration pour échapper au conteneur, Microsoft considère qu’il s’agit d’un bogue non lié à la sécurité et le corrige conformément au processus de maintenance normal. Si une attaque utilise un processus non administrateur pour effectuer une action qui enfreint une limite de sécurité, Microsoft l’examine conformément aux critères de maintenance de sécurité établis .

Qu’est-ce qui rend une charge de travail mutualisée hostile ?

Les environnements multilocataires existent quand plusieurs charges de travail fonctionnent sur l’infrastructure et les ressources partagées. Si une ou plusieurs charges de travail s’exécutant sur une infrastructure ne peuvent pas être approuvées, l’environnement multilocataire est considéré comme hostile. Les conteneurs Windows Server et Linux partagent le noyau hôte, de sorte que toute attaque effectuée sur un seul conteneur peut avoir un impact sur toutes les autres charges de travail exécutées sur l’infrastructure partagée.

Vous pouvez prendre des mesures pour réduire le risque qu’un exploit se produise, par exemple, à l’aide de stratégies de sécurité de pod, d’AppArmor et de contrôle d’accès en fonction du rôle (RBAC), mais ils ne fournissent pas de protection garantie contre un attaquant. Nous vous recommandons de suivre nos bonnes pratiques concernant l’isolation des clusters dans tout scénario multilocataire.

Quand utiliser des comptes d’utilisateur ContainerAdmin et ContainerUser

Les conteneurs Windows Server offrent deux comptes d’utilisateur par défaut, ContainerUser et ContainerAdministrator, chacun ayant leur propre objectif spécifique. Le compte ContainerAdministrator vous permet d’utiliser le conteneur à des fins d’administration : installation de services et de logiciels (par exemple, activation d’IIS au sein d’un conteneur), modification de la configuration et création de comptes. Ces tâches sont importantes pour un certain nombre de scénarios informatiques qui peuvent s’exécuter dans des environnements de déploiement locaux personnalisés.

Le compte ContainerUser existe pour tous les autres scénarios où les privilèges d’administrateur dans Windows ne sont pas nécessaires. Par exemple, dans Kubernetes, si l’utilisateur est ContainerAdministrator et hostvolumes sont autorisés à être montés dans le pod, l’utilisateur peut monter le dossier .ssh et ajouter une clé publique. En tant que ContainerUser, cet exemple ne serait pas possible. Il s’agit d’un compte d’utilisateur restreint conçu uniquement pour les applications qui n’ont pas besoin d’interagir avec l’hôte. Nous vous recommandons vivement que, lors du déploiement d'un conteneur Windows Server dans n'importe quel environnement mutualisé, votre application s'exécute via le compte ContainerUser. Dans un environnement multilocataire, il est toujours préférable de suivre le principe de privilège minimum, car si un attaquant compromet votre charge de travail, les charges de travail partagées et voisines ont également une plus faible probabilité d’être impactées. L’exécution de conteneurs avec le compte ContainerUser réduit considérablement le risque que l’environnement soit compromis dans son ensemble. Toutefois, cela ne fournit toujours pas de limite de sécurité robuste. Par conséquent, lorsque la sécurité est une préoccupation, vous devriez utiliser des conteneurs isolés par un hyperviseur.

Pour modifier le compte d’utilisateur, vous pouvez utiliser l’instruction USER sur votre fichier dockerfile :

USER ContainerUser

Vous pouvez également créer un utilisateur :

RUN net user username ‘<password>’ /ADD
USER username

Services de Windows

Les services Microsoft Windows, anciennement appelés services NT, vous permettent de créer des applications exécutables longues qui s’exécutent dans leurs propres sessions Windows. Ces services peuvent être démarrés automatiquement au démarrage du système d’exploitation, peuvent être suspendus et redémarrés, et n’affichent aucune interface utilisateur. Vous pouvez également exécuter des services dans le contexte de sécurité d’un compte d’utilisateur spécifique différent de l’utilisateur connecté ou du compte d’ordinateur par défaut.

Lors de la conteneurisation et de la sécurisation d’une charge de travail qui s’exécute en tant que service Windows, il existe quelques considérations supplémentaires à prendre en compte. D'abord, la ENTRYPOINT du conteneur ne sera pas la charge de travail, car le service s'exécute comme un processus en arrière-plan. Généralement, l'ENTRYPOINT sera un outil comme le moniteur de service ) ou le moniteur de journal ). Deuxièmement, le compte de sécurité sous lequel la charge de travail fonctionne sera configuré par le service et non par la directive USER dans le fichier dockerfile. Vous pouvez vérifier le compte sous lequel le service s’exécutera en exécutant Get-WmiObject win32_service -filter "name='<servicename>'" | Format-List StartName.

Par exemple, lors de l’hébergement d’une application web IIS à l’aide de l’image ASP.NET (Microsoft Artifact Registry) l'ENTRYPOINT du conteneur est "C:\\ServiceMonitor.exe", "w3svc". Cet outil peut être utilisé pour configurer le service IIS, puis surveille le service pour s’assurer qu’il reste en cours d’exécution et se ferme, arrêtant ainsi le conteneur, si le service s’arrête pour une raison quelconque. Par défaut, le service IIS et donc l’application web s’exécutent sous un compte à privilèges faibles au sein du conteneur, mais l’outil de surveillance de service nécessite des privilèges d’administration pour configurer et surveiller le service.