ClickCease Comment KernelCare vous aide à sécuriser vos charges de travail conteneurisées - TuxCare

Rejoignez notre populaire bulletin d'information

Rejoignez 4 500+ professionnels de Linux et de l'Open Source !

2 fois par mois. Pas de spam.

Comment KernelCare vous aide à sécuriser vos charges de travail conteneurisées

Le 6 janvier 2021 - L'équipe de relations publiques de TuxCare

Comment KernelCare vous aide à sécuriser vos charges de travail conteneuriséesLa virtualisation des systèmes d'exploitation a constitué un énorme pas en avant pour la fourniture d'applications informatiques d'entreprise à grande échelle. Mais les machines virtuelles n'étaient qu'un début. Les conteneurs font progresser la virtualisation d'un cran, offrant une flexibilité sans précédent, les applications devenant transportables de manière presque transparente.

Cependant, les conteneurs s'accompagnent d'un risque de sécurité caché qui découle de la nature de la conteneurisation. Dans cet article, nous abordons le rôle de la conteneurisation dans l'entreprise, expliquons pourquoi les conteneurs peuvent constituer un risque pour la sécurité de l'entreprise - et indiquons des solutions efficaces.

Contenu :

  1. Qu'est-ce qu'une charge de travail conteneurisée ?

  2. De la virtualisation à la conteneurisation

  3. Comment les conteneurs sont utilisés dans l'entreprise

  4. La relation entre les conteneurs et l'hôte

  5. Isolé, oui, mais toujours vulnérable

  6. Noyaux non corrigés : Un risque caché pour la sécurité des conteneurs ?

  7. Le problème avec les noyaux de patchs

  8. Intégration de KernelCare Live Patching

  9. Autres conseils pour la sécurité du noyau des conteneurs

  10. Conclusion

 

Attendez. Qu'est-ce qu'une charge de travail conteneurisée ?

Pour comprendre pourquoi les conteneurs peuvent représenter un risque pour la sécurité, vous devez comprendre ce qu'est exactement un conteneur - et ce qu'est une charge de travail conteneurisée.

Tout d'abord, un retour en arrière sur la virtualisation. Il n'y a pas si longtemps, le système d'exploitation d'un ordinateur et le matériel sur lequel il fonctionne étaient inextricablement liés - un serveur physique est associé à un système d'exploitation. La virtualisation change cela en insérant une couche entre le matériel et le système d'exploitation qui fonctionne dessus. Elle supprime la relation univoque et contraignante entre le système d'exploitation et le matériel.

Pour un système d'exploitation virtualisé, il semble qu'il soit le seul système d'exploitation sur le matériel. En arrière-plan, le logiciel de virtualisation (l'hyperviseur) gère la couche d'abstraction afin que chaque système d'exploitation ignore la présence d'autres systèmes d'exploitation sur la machine.

Grâce à la virtualisation, vous pouvez exécuter plusieurs systèmes d'exploitation sur une seule machine, et transporter facilement un système d'exploitation d'une machine à l'autre. Vous bénéficiez ainsi d'un gain d'efficacité et de flexibilité.

 

De la virtualisation à la conteneurisation

Nous faisons référence à la virtualisation car elle permet d'expliquer ce que fait la conteneurisation. Alors que la virtualisation place une couche d'abstraction entre l'équipement physique et le système d'exploitation, la conteneurisation ajoute une couche d'abstraction entre le système d'exploitation - et l'application.

Essentiellement, là où la virtualisation virtualise le matériel, la conteneurisation virtualise le système d'exploitation. Avec la conteneurisation, chaque application est encapsulée dans une unité isolée appelée conteneur. Les applications conteneurisées ne partagent pas l'environnement du système d'exploitation, car chaque conteneur fonctionne de manière discrète.

Cependant, les conteneurs partagent un accès en lecture seule aux éléments du système d'exploitation, y compris son noyau. Néanmoins, pour chaque application, il semble qu'elle fonctionne seule dans un système d'exploitation qui lui est propre - et les applications ignorent mutuellement qu'elles partagent l'environnement du système d'exploitation.

Par conséquent, une charge de travail conteneurisée désigne un environnement dans lequel les applications qui répondent aux besoins de l'entreprise sont exécutées dans des conteneurs isolés à l'intérieur d'un système d'exploitation hôte.

 

Comment les conteneurs sont utilisés dans l'entreprise

On pourrait penser que l'isolation des applications à l'intérieur de conteneurs présente des avantages en termes de sécurité et de stabilité, et on aurait raison. Cependant, les avantages de la conteneurisation vont bien au-delà.

À la base, la conteneurisation permet aux entreprises de conditionner et de déployer des applications sur différents types d'infrastructures de manière standardisée. En théorie, tout hôte capable d'accueillir un conteneur (compatible) est également capable d'accueillir votre application conteneurisée.

Cela se produit parce que la conteneurisation abstrait la couche d'application. La technologie des conteneurs, comme Docker, facilite cette abstraction d'une manière standardisée. La clé de ce comportement normalisé est ce que l'on appelle une image de conteneur. Une image de conteneur comprend non seulement le code de l'application, mais aussi les bibliothèques système et d'autres paramètres clés qui garantissent qu'une application conteneurisée est prête à fonctionner.

Cela nous amène à un avantage clé de la conteneurisation qui va au-delà de la sécurité et de la stabilité des applications : les conteneurs sont intrinsèquement portables. Il en résulte plusieurs avantages importants pour les applications d'entreprise :

  • La portabilité est synonyme d'agilité. Les applications conteneurisées peuvent facilement être exécutées dans un nouvel environnement non familier. Un développeur peut publier une image de conteneur et les entreprises clientes peuvent déployer l'application en toute confiance, à condition que le conteneur corresponde à un environnement conteneurisé standard tel que Docker. Les conteneurs permettent un déploiement d'applications incroyablement agile.
  • Les conteneurs nécessitent peu de ressources. Il est facile et rapide de mettre en service une application conteneurisée - bien plus facile et rapide que de démarrer un système d'exploitation virtuel complet. En même temps, une seule machine hôte peut prendre en charge beaucoup plus de conteneurs que d'instances de systèmes d'exploitation virtuels. C'est pourquoi les conteneurs présentent des avantages encore plus importants que la virtualisation en matière d'efficacité des centres de données.
  • Déploiement et gestion automatisés. La nature standardisée des conteneurs signifie que les entreprises peuvent déployer et gérer dynamiquement les applications conteneurisées. C'est ce qu'on appelle l'orchestration de conteneurs. Les outils d'orchestration tels que Kubernetes automatisent le déploiement et la surveillance des applications à grande échelle.

La conteneurisation étend et amplifie les avantages de la virtualisation. Les entreprises bénéficient de niveaux d'évolutivité et de gestion sans précédent lorsque les applications sont déployées via des conteneurs standardisés.

 

La relation entre les conteneurs et l'hôte

La conteneurisation offre des avantages considérables, notamment en ce qui concerne les applications d'entreprise à grande échelle.

Cependant, les conteneurs représentent un changement radical dans la façon dont les applications sont déployées. D'un point de vue pratique et même sécuritaire, il est utile d'avoir une idée de la relation entre un conteneur et son hôte.

S'il est vrai que les conteneurs fonctionnent de manière isolée, il est important de comprendre que les conteneurs partagent également des composants. Cela évite d'avoir à exécuter un système d'exploitation distinct pour chaque application dans un conteneur.

Cela signifie également que les conteneurs sont plus rapides à démarrer - par rapport à un système d'exploitation complet. Alors, quels éléments de l'hôte sont partagés par les conteneurs ? Le noyau du système d'exploitation est l'aspect partagé le plus important : il n'y a qu'un seul noyau en cours d'exécution dans l'hôte et chaque conteneur dans l'hôte partage ce noyau.

Ensuite, les pilotes et les binaires d'application du système d'exploitation sont partagés par les conteneurs - tandis que les conteneurs partagent également le stockage du système d'exploitation hôte, bien que le stockage soit isolé. Enfin, les conteneurs partagent également la plateforme de conteneurs - comme Docker, par exemple.

La capacité des conteneurs à s'exécuter de manière aussi isolée découle de quelques fonctionnalités de base de Linux utilisées par les plateformes de conteneurs (par exemple, Docker) pour renforcer l'isolement. Les espaces de noms du noyau et les cgroups permettent à des conteneurs indépendants de partager le même hôte Linux.

 

Isolé, oui, mais toujours vulnérable

Il est clair que les conteneurs offrent un niveau élevé d'isolation, qui offre à son tour un certain degré de protection - les menaces ne peuvent pas se propager d'une application à l'autre aussi facilement.

Cependant, en raison du partage des ressources inhérent aux charges de travail conteneurisées, les conteneurs restent vulnérables - et peuvent même introduire de nouvelles vulnérabilités auxquelles les organisations doivent faire attention. Examinons quelques exemples :

  • Sécurité des images. Il est essentiel de s'assurer que vous n'exécutez que des images de conteneurs provenant d'une source fiable. Une image empoisonnée ou une image non corrigée peut ouvrir la porte à des attaques. La sécurité et la sûreté des images sont vraiment importantes.
  • Sécurité de la plate-forme de conteneurs. Comme tout autre logiciel, votre plateforme de conteneurs peut comporter des risques de sécurité. Considérez par exemple la vulnérabilité d'exécution à distance de l'accès root de runCinhérente aux bibliothèques runC qui sont couramment utilisées par les fournisseurs de logiciels de conteneurs.
  • Risque d'escalade des privilèges. Bien que les applications ne devraient pas, en théorie, sortir des conteneurs, il convient de faire très attention aux privilèges des utilisateurs utilisés dans un conteneur. Si une application de conteneur dispose d'un accès root pour une raison quelconque, le risque existe qu'un breakout donne à l'attaquant un accès root à l'ensemble de votre machine. Le risque runC décrit au point précédent est typique d'un risque de sécurité de type "breakout".

Ainsi, si les applications sont isolées, le mécanisme d'isolation - les conteneurs - présente ses propres risques de sécurité. Les entreprises doivent donc gérer leurs charges de travail conteneurisées de manière à atténuer ces risques.

 

Noyaux non corrigés : Un risque caché pour la sécurité des conteneurs ?

Les composants partagés des conteneurs entraînent clairement des risques de sécurité. Mais le plus grand risque de sécurité pour les applications conteneurisées est sans doute le noyau de l'OS partagé. Les risques de sécurité posés par le noyau de l'hôte se cachent essentiellement à la vue de tous.

N'oubliez pas : chaque conteneur dans un hôte partage le même noyau de système d'exploitation. Les organisations risquent de mal comprendre les avantages de la conteneurisation en termes d'isolation et donc de sécurité en négligeant de prendre en compte les risques posés par un noyau de système d'exploitation partagé.

Cependant, une fois que le noyau du système d'exploitation est compromis, l'application à l'intérieur du conteneur peut également être compromise. Et nous savons que les noyaux de systèmes d'exploitation sont depuis longtemps à l'origine de failles de sécurité de toutes formes et de toutes tailles.

C'est pourquoi la sécurité du noyau est si importante lorsqu'il s'agit de sécuriser des charges de travail conteneurisées. Il y a plusieurs choses que vous pouvez faire pour garantir un noyau sécurisé pour votre charge de travail conteneurisée : restez au courant des derniers risques de sécurité du noyau et assurez-vous que votre noyau Linux ne contient que les services dont vous avez besoin pour les charges de travail conteneurisées.

N'oubliez pas, bien sûr, les correctifs du noyau.

 

Le problème avec les noyaux de patchs

Le noyau Linux est continuellement corrigé. Au fur et à mesure que des vulnérabilités apparaissent, la communauté ajuste le code du noyau Linux pour combattre ces vulnérabilités et publie un correctif. Les systèmes non corrigés sont en danger, les systèmes corrigés ne le sont pas.

L'application de correctifs ne devrait pas poser de problème : il s'agit d'une mesure de sécurité simple qui améliore considérablement la sécurité de vos conteneurs. Pourtant, l'application systématique de correctifs peut s'avérer très difficile :

  • L'application de correctifs prend beaucoup de temps. Compte tenu du volume des correctifs du noyau Linux qui sont publiés, de nombreuses organisations ont du mal à garder une longueur d'avance sur les correctifs, en particulier dans les grands parcs technologiques comprenant des milliers de machines.
  • L'application cohérente de correctifs est coûteuse. À moins d'être automatisé, le déploiement des correctifs peut épuiser les ressources des meilleures équipes techniques. L'application de correctifs devient un processus coûteux et une cible facile pour les économies et les réductions de coûts.
  • La mise à jour est perturbatrice. Un correctif du noyau nécessite souvent un redémarrage du serveur. Pour de nombreuses charges de travail, un redémarrage sera très perturbant. Le redémarrage d'un conteneur peut être très rapide - le redémarrage de l'hôte entier peut entraîner une interruption de service notable. Par conséquent, les correctifs sont souvent retardés.

Il est clair que l'un des plus grands risques de sécurité pour les charges de travail conteneurisées est, en fait, très difficile à gérer de manière cohérente.

 

Intégration de KernelCare Live Patching

L'automatisation de la mise à jour est la première étape pour réduire les risques de vulnérabilité du noyau dans les charges de travail conteneurisées. Une autre étape essentielle est le "live kernel patching" : la possibilité de mettre à jour le noyau du système d'exploitation sans nécessiter le redémarrage du serveur. KernelCare live patching offre les deux.

Les entreprises qui gèrent des charges de travail conteneurisées peuvent utiliser KernelCare pour s'assurer que les noyaux de leurs hôtes conteneurisés sont systématiquement corrigés, et ce sans interruption. La procédure est simple : il suffit d'installer KernelCare comme vous le feriez normalement.

Lorsque vous utilisez KernelCare pour patcher vos hôtes de conteneurs, vous bénéficiez également, par conséquent, d'un patching entièrement automatisé du noyau utilisé par les conteneurs. Comme les conteneurs partagent le noyau de l'hôte, vous n'avez besoin d'installer KernelCare sur votre hôte de conteneurs qu'une seule fois - et les mises à jour du noyau s'appliqueront à tous les conteneurs sur cet hôte.

En bref, KernelCare est un moyen efficace et pratique de gérer l'un des plus grands risques de sécurité associés à la conteneurisation.

 

Autres conseils pour la sécurité du noyau des conteneurs

Avant de conclure l'article, nous allons aborder quelques autres points qui méritent d'être pris en compte pour assurer la sécurité du noyau de votre hôte de conteneur. Oui, l'application de correctifs est essentielle, mais vous devriez également tenir compte des points suivants, dont la plupart sont simplement de bonnes pratiques pour la sécurité des serveurs :

  • Supprimez l'utilisateur root. En limitant l'utilisateur root, vous pouvez vous assurer qu'un conteneur qui sort de l'isolation n'obtient pas automatiquement un accès root à l'ensemble du serveur.
  • Limiter les modules du noyau que vous exécutez. Lorsque vous configurez un serveur, vous pouvez l'étendre en ajoutant des modules de noyau. Pour une sécurité maximale, nous vous suggérons d'installer le minimum absolu de modules de noyau dont vous avez besoin pour votre environnement conteneurisé - mais veillez à conserver les modules critiques qui appliquent la sécurité aux rôles et aux autorisations.
  • Utilisez les outils de sécurité des conteneurs. Il existe des outils spécifiquement développés pour analyser la configuration de votre conteneur et la comparer aux meilleures pratiques. docker-bench-security en est un exemple, il vérifie des dizaines de points dans votre configuration et l'évalue selon les règles des meilleures pratiques.

Comme toujours, une sécurité complète exige une configuration minutieuse du serveur et une gestion continue et proactive de celui-ci.

 

Conclusion

La conteneurisation transforme les charges de travail des applications d'entreprise en réduisant le coût de l'infrastructure, en accélérant le processus de déploiement des applications et en introduisant une flexibilité et une évolutivité sans précédent.

Cependant, l'exécution d'applications à l'intérieur de conteneurs présente également des risques de sécurité uniques qui ne sont pas toujours évidents. La sécurité du noyau et les correctifs sont un domaine critique qui doit être traité avec beaucoup de soin.

KernelCare permet à votre entreprise de mettre automatiquement à jour les noyaux qui prennent en charge vos charges de travail conteneurisées, et ce, sans les perturbations et les temps d'arrêt associés aux redémarrages du système.

Vous cherchez à automatiser la correction des vulnérabilités sans redémarrage du noyau, temps d'arrêt du système ou fenêtres de maintenance programmées ?

Découvrez le Live Patching avec TuxCare

Devenez rédacteur invité de TuxCare

Commencer

Courrier

Rejoindre

4,500

Professionnels de Linux et de l'Open Source
!

S'abonner à
notre lettre d'information