La sécurité des conteneurs, qu'est-ce que c'est ?

La sécurité des conteneurs consiste à définir et appliquer des pratiques de création, de déploiement et d'exécution qui protègent un conteneur Linux complet, c'est-à-dire des applications qu'il prend en charge jusqu'à l'infrastructure sur laquelle il repose.

Aujourd'hui, les entreprises adoptent des modèles de conception de microservices et des technologies de conteneurs, telles que Docker et Kubernetes. Pour les équipes de sécurité, cela implique de développer des solutions de sécurité des conteneurs qui facilitent ces changements d'infrastructure. La sécurité des conteneurs doit être intégrée et continue, pour garantir la sécurité globale d'une entreprise. 

Élément clé de la sécurisation des conteneurs, la solution d'orchestration Kubernetes vous offre un accès à des données contextuelles riches pour une meilleure visibilité et conformité, l'établissement du profil de risques en fonction du contexte, la mise en réseau ainsi que la détection dans votre environnement d'exécution. Une sécurité efficace des conteneurs s'appuie sur des constructions Kubernetes telles que les déploiements, les pods, les politiques de réseau, etc. Par exemple, les politiques réseau de Kubernetes sont une fonction de sécurité intégrée qui permet de contrôler les communications pod à pod et de réduire l'exposition aux menaces.

Pour assurer la sécurité continue des conteneurs, il faut généralement :

• sécuriser le pipeline de conteneurs et l'application ;
• sécuriser l'environnement de déploiement des conteneurs et l'infrastructure ;
• sécuriser les charges de travail conteneurisées lors de l'exécution.

Découvrez comment les entreprises mettent en œuvre des initiatives de sécurité des conteneurs.

S'il est possible de contrôler la sécurité avec une phase finale de test dans le cadre du développement logiciel traditionnel, ce n'est pas le cas pour le développement d'applications cloud-native moderne. En effet, la surface d'attaque est bien plus grande et les problèmes de sécurité bien plus complexes. Dans les environnements cloud-native, où les conteneurs représentent le format standard de distribution des applications, le code est régulièrement mis à jour et intégré à partir de différents référentiels. Les erreurs humaines, telles que les mauvaises configurations, favorisent les accès non autorisés à différentes phases du cycle de développement et de déploiement. Les failles de sécurité peuvent apparaître presque partout, il est donc important d'intégrer la sécurité en tant que processus continu.

Si le déploiement des conteneurs est automatisé (à l'aide d'outils d'orchestration comme Kubernetes), la sécurité doit l'être également. Les principes DevSecOps (qui visent à intégrer la sécurité dans le DevOps) permettent de corriger et contrôler le code en continu tout au long du cycle de développement. Il est ainsi possible de détecter et corriger les vulnérabilités rapidement, avant qu'elles ne deviennent des problèmes chronophages. Parce qu'ils sont immuables, les conteneurs doivent être sécurisés en corrigeant le code lors de la phase de création et non pendant l'exécution. Cette approche évite la réapparition des vulnérabilités lorsque les conteneurs sont détruits puis reconstruits.

L'analyse des images de conteneurs pour détecter les logiciels malveillants et d'autres failles de sécurité est une étape essentielle qui constitue l'une des nombreuses couches de sécurité. Les entreprises doivent prendre en compte la sécurité de l'ensemble de la chaîne d'approvisionnement des logiciels, à savoir toutes les étapes du développement et du déploiement des logiciels conteneurisés, y compris les dépendances et les environnements d'exécution. 

Voici quelques stratégies de développement conteneurisé qui ont pour but de sécuriser la chaîne d'approvisionnement :

• Un contenu fiable et un référentiel de contenu adapté aux entreprises permettent d'obtenir des images renforcées grâce à une sécurité et à des contrôles d'accès avancés.
• Une approche Zero Trust attribue les plus faibles niveaux d'accès aux ressources critiques.
• L'approche Policy as Code intègre des contrôles de sécurité directement dans le pipeline CI/CD.
• La signature et les vérifications imposent l'attestation et instaurent la confiance en contrôlant que les images de conteneurs n'ont pas été altérées.
• Les pratiques GitOps permettent de gérer les configurations de sécurité des applications et des conteneurs.

Collectez des images

Les conteneurs sont constitués de couches de fichiers appelés images de conteneur. 

Un outil tel que Buildah vous permet de créer des images compatibles OCI et Docker à partir de zéro, en se basant ou non sur une image de conteneur existante.

Les images de conteneurs sont le format de distribution d'applications standard dans les environnements cloud-native, mais même les entreprises cloud-native distribuent leurs charges de travail entre plusieurs fournisseurs de cloud. La solution de sécurité des conteneurs idéale doit prendre en charge toutes les architectures, quel que soit l'environnement d'exécution de votre infrastructure : système privé, datacenter partagé, ou encore cloud public comme Amazon Web Services (AWS), Microsoft Azure ou Google Cloud Platform.

L'image de base, ou image maître, est l'une des plus importantes en matière de sécurité, car elle sert de point de départ pour la création d'images dérivées. La sécurité des conteneurs commence donc par l'identification de sources fiables pour les images de base. Vérifiez que l'image provient d'une entreprise connue ou d'un groupe Open Source, qu'elle est hébergée dans un registre réputé fiable, et que le code source de tous les composants de l'image est disponible.

Toutefois, même avec des images fiables, l'ajout d'applications et les changements de configuration introduisent de nouvelles variables. Lorsque vous ajoutez du contenu externe pour créer vos applications, vous devez garder à l'esprit les principes de gestion proactive des vulnérabilités.

• Utilisez un outil d'analyse des images intégré au registre ou distinct pour examiner toutes les images de façon régulière. Privilégiez un outil qui réalise des analyses en fonction de langages, paquets et couches d'images spécifiques.
• Identifiez les images de conteneurs modifiées qui enfreignent les politiques ou les meilleures pratiques documentées (appelées erreurs de configuration de conteneur) afin de réduire la probabilité d'une compromission et ses répercussions.

Anticipez et corrigez les vulnérabilités

Les conteneurs sont largement utilisés, car ils facilitent la création, la mise en paquets et la promotion d'une application ou d'un service et de toutes leurs dépendances, tout au long du cycle de vie et dans différents workflows et cibles de déploiement. Néanmoins, la sécurité des conteneurs peut être difficile à mettre en œuvre. Si les conteneurs vous aident à mieux contrôler la sécurité au niveau des charges de travail, ils introduisent aussi de nouveaux composants d'infrastructure, ainsi que des surfaces d'attaque inconnues. La solution de sécurité des conteneurs idéale doit contribuer à la sécurité de l'infrastructure du cluster et de l'orchestrateur ainsi que des applications conteneurisées qu'ils exécutent.

Les politiques de sécurité et les listes de contrôle statiques ne s'adaptent pas aux conteneurs de l'entreprise :

• La chaîne d'approvisionnement nécessite davantage de services en matière de politiques de sécurité.
• Les équipes de sécurité doivent trouver un équilibre entre les besoins du réseau et les impératifs de gouvernance liés aux environnements conteneurisés.
• Les outils utilisés pendant les phases de création, de maintenance et de service doivent avoir des politiques d'autorisation différentes.

Un programme efficace de sécurité des conteneurs vise à corriger les vulnérabilités en temps réel et à réduire la surface d'attaque avant le déploiement des images, tout en conservant les données sur l'origine. En sécurisant votre pipeline de conteneurs et en protégeant votre infrastructure, vous aurez l'assurance que vos conteneurs sont fiables, évolutifs et sûrs.

Avant de collecter des images de conteneurs, posez-vous les questions suivantes :

• Les images de conteneurs sont-elles signées et issues de sources fiables ?
• D'où vient l'image, et comment puis-je la recréer ?
• Quand l'image a-t-elle été analysée pour la dernière fois ?
• Les couches d'exécution et du système d'exploitation sont-elles à jour ?
• À quelle fréquence les conteneurs seront-ils mis à jour et combien de temps dureront ces opérations ?
• Des risques de sécurité ont-ils été identifiés et comment seront-ils suivis ?

Une fois la collecte terminée, l'étape suivante consiste à gérer l'accès à ces images et leur partage avec l'équipe qui les utilise. Cela implique de protéger les images que vous téléchargez et celles que vous créez. L'utilisation d'un registre privé vous permet de contrôler l'accès en fonction des rôles et facilite la gestion du contenu grâce à l'affectation de métadonnées pertinentes au conteneur. Ces métadonnées vous aideront ensuite à identifier et à suivre les vulnérabilités connues. Avec un registre de conteneurs privé, vous pouvez également automatiser et affecter des politiques aux images stockées, tout en limitant les risques d'erreurs humaines qui peuvent être à l'origine de vulnérabilités dans vos environnements de conteneurs. Les registres de conteneurs dotés de fonctionnalités de sécurité adaptées aux entreprises comprennent également des outils d'analyse des vulnérabilités.

Pour définir la méthode de gestion des accès, posez-vous les questions suivantes :

• Quels contrôles d'accès basés sur les rôles faut-il mettre en place pour gérer les images de conteneurs ?
• Des fonctionnalités d’étiquetage sont-elles prévues pour faciliter le tri des images ? Les images peuvent-elles être étiquetées pour indiquer qu'elles ont été approuvées uniquement pour le développement, puis pour les tests et enfin pour les environnements de production ?
• Le registre fournit-il des métadonnées visibles qui permettent de suivre des vulnérabilités connues ?
• Le registre peut-il être utilisé pour affecter et automatiser une politique (par exemple, la vérification de signatures, l'analyse de code applicatif, etc.) ?

La dernière étape du pipeline est le déploiement. Une fois les versions créées, vous devez les gérer conformément aux normes du secteur, telles que les critères CIS (Center for Internet Security) et les directives du NIST (National Institute of Standards and Technology). Pour cela, vous devez comprendre comment automatiser des politiques qui permettent de signaler les versions présentant des problèmes de sécurité, notamment en cas de détection de nouvelles vulnérabilités. Bien que l'analyse des vulnérabilités reste importante, elle n'est qu'une initiative de sécurité parmi toutes celles qui servent à protéger vos environnements de conteneurs.

Puisque l'application de correctifs n'est pas aussi efficace qu'une reconstruction des conteneurs, l'intégration de tests de sécurité doit inclure la définition de politiques qui déclenchent des reconstructions automatiques. La première étape de cette démarche consiste à exécuter des outils d'analyse des composants pour suivre et signaler les problèmes. La seconde étape vise à mettre en place des outils qui permettent des déploiements automatisés et basés sur des politiques.

Au moment d'intégrer des tests de sécurité et d'automatiser le déploiement, posez-vous les questions suivantes :

• Mes conteneurs contiennent-ils des vulnérabilités à corriger avant d'effectuer leur déploiement dans un environnement de production ?
• Mes déploiements sont-ils configurés correctement ? Certains conteneurs disposent-ils de privilèges excessifs sans raison particulière ? Est-ce que j'utilise un système de fichiers root en lecture seule ?
• Dans quelle mesure suis-je conforme aux benchmarks CIS et au cadre NIST SP 800-190 ?
• Ai-je isolé les charges de travail jugées sensibles à l'aide de fonctions intégrées telles que les politiques réseau et les espaces de nom ?
• Est-ce que j'utilise des fonctions de sécurité et de renforcement intégrées telles que les profils SELinux, AppArmor et seccomp ?

La sécurité des conteneurs continue d'être assurée après les tests et le déploiement, et lors de l'exécution des applications conteneurisées. Des aspects tels que la détection des menaces, la sécurité du réseau et la résolution des incidents deviennent plus pertinents.

Lors de l'exécution, les applications peuvent faire l'objet de menaces réelles et imprévisibles, et les vulnérabilités ainsi que les erreurs de configuration manquées pendant la conception peuvent être exploitées. Pour sécuriser l'exécution, il est nécessaire d'inclure la surveillance des comportements inattendus au niveau des applications. Le repérage des anomalies pendant l'exécution permet de détecter la réattribution des privilèges, le cryptominage, des flux de réseau inattendus, des fuites de conteneurs et d'autres comportements non sécurisés.

La segmentation du réseau est un autre élément à prendre en compte pour réduire la surface d'attaque. Dans Kubernetes, les politiques réseau par défaut autorisent les pods d'un même cluster à communiquer entre eux. Dans le cadre de votre politique Zero Trust, assurez-vous qu'un pod compromis ne pourra pas affecter l'ensemble des pods du cluster.

Enfin, les stratégies de résolution des incidents peuvent aider les équipes à réagir de manière appropriée aux événements. Elles peuvent notamment envoyer les événements en question à un système de gestion des informations et des événements de sécurité (SIEM), signaler l'incident au propriétaire de l'application en lui communiquant les informations détaillées et les mesures à prendre concernant le déploiement à corriger, ou encore arrêter et redémarrer automatiquement les pods. Ces actions doivent suivre les pratiques de reconstruction et de redéploiement des conteneurs problématiques, plutôt que de corriger les conteneurs en cours d'exécution.

Le système d'exploitation de l'hôte/du nœud du conteneur lui fournit une couche supplémentaire de sécurité en l'isolant. Vous avez donc besoin d'un système d'exploitation hôte qui isole au maximum les conteneurs. Cette isolation joue un rôle primordial dans la protection de l'environnement de déploiement des conteneurs. Lorsqu'il se trouve dans un environnement Kubernetes conteneurisé, le système d'exploitation hôte est partagé entre les conteneurs et géré par un outil d'exécution des conteneurs, qui interagit avec Kubernetes pour créer et gérer des conteneurs (ou des pods de conteneurs). 

Le système d'exploitation doit être isolé du conteneur pour éviter qu'un seul conteneur compromis n'affecte le système d'exploitation hôte et les autres conteneurs. Pour rendre votre plateforme de conteneurs résiliente, utilisez des espaces de noms réseau qui isolent les applications et les environnements, et associez le système de stockage à l'aide de mécanismes de montage sécurisés. Dans votre configuration, l'outil d'exécution des conteneurs ne doit pas pouvoir partager l'espace de noms du réseau hôte, de l'IPC ou de l'UPC. Choisissez un système d'exploitation hôte renforcé et optimisé pour les conteneurs et utilisez un outil d'analyse des vulnérabilités pour l'hôte.

Une solution de gestion des API doit comprendre l'authentification et l'autorisation, l'intégration LDAP, des contrôles d'accès des points de terminaison et la limitation du débit.

Lors de l'élaboration de la stratégie de protection de l'infrastructure de conteneurs, posez-vous les questions suivantes :

• Quels conteneurs doivent pouvoir accéder à d'autres conteneurs ? Comment s'effectue leur détection ?
• Comment contrôler l'accès aux ressources partagées (réseau, stockage, etc.) et leur gestion ?
• Comment surveiller l'intégrité des conteneurs ?
• Comment faire évoluer automatiquement la capacité des applications pour répondre à la demande ?
• Comment gérer les mises à jour de l'hôte ? Tous les conteneurs devront-ils être mis à jour simultanément ?

La plateforme Red Hat® OpenShift® comprend Red Hat Enterprise Linux®. Elle automatise le cycle de vie des applications conteneurisées, sécurise le pipeline de conteneurs et vous permet de passer d'une stratégie DevOps à une stratégie DevSecOps. Notre catalogue de conteneurs vous donne accès à un grand nombre d'images, d'environnements d'exécution de langage, de bases de données et de solutions de middleware certifiés qui peuvent s'exécuter partout où vous exécutez Red Hat Enterprise Linux. Les images que nous fournissons sont toujours signées et vérifiées pour garantir leur origine et leur intégrité.

Nous analysons en continu nos images de conteneurs pour détecter d'éventuelles vulnérabilités, notamment à l'aide d'un index d'intégrité accessible au public et mis à jour en permanence. Nous publions également des mises à jour de sécurité et des reconstructions de conteneurs dans notre registre public. Red Hat Advanced Cluster Security for Kubernetes s'intègre aux outils DevOps et de sécurité pour vous permettre de limiter les menaces et d'appliquer des politiques de sécurité qui protègent vos applications des risques liés à l'exploitation.

Red Hat Service Interconnect permet aux conteneurs de communiquer les uns avec les autres tout en réduisant les risques pour la sécurité de votre entreprise ou les données de l'utilisateur.

Nos partenaires de sécurité complètent et étendent certaines de nos capacités de sécurité pour les conteneurs avec des intégrations certifiées. Des fonctions de sécurité sont intégrées à la plateforme Red Hat OpenShift. Associées aux solutions de sécurité de nos partenaires, elles protègent les applications et conteneurs tout au long du cycle de vie DevOps.

Autres avantages de nos solutions :

• Orchestration et gestion de conteneurs à l'échelle du Web
• Console web élaborée avec fonctions de collaboration à plusieurs utilisateurs
• Interfaces CLI et IDE
• Intégration au pipeline CI
• Automatisation des builds et capacités S2I (source-to-image)
• Automatisation du déploiement
• Prise en charge de volumes de stockage distants
• Installation et administration simplifiées
• Prise en charge d'une grande variété de langages de programmation, frameworks et services