Remarque perev. : L'article original a été écrit par un ingénieur suédois - Christian Abdelmassih, qui aime l'architecture au niveau de l'entreprise, la sécurité informatique et le cloud computing. Récemment, il a obtenu une maîtrise en informatique et est pressé de partager son travail - une thèse de maîtrise, ou plutôt une partie de celle-ci, consacrée aux problèmes d'isolement d'une application conteneurisée [et lancée dans Kubernetes]. En tant que «client» pour lequel ce travail de recherche a été préparé, il agit tout autant que la police de son pays d'origine.
L'orchestration de conteneurs et l'informatique native dans le cloud sont devenues très populaires ces dernières années. Leur adaptation a atteint un niveau tel que même les entreprises financières, les banques et le secteur public s'y intéressent. Par rapport à d'autres entreprises, elles se distinguent par des exigences importantes dans le domaine de la sécurité de l'information et de l'informatique.
L'un des aspects importants est la façon dont les conteneurs peuvent être utilisés dans les environnements de production et en même temps, la séparation du système entre les applications peut être maintenue. Étant donné que ces organisations utilisent des environnements de cloud privé basés sur la virtualisation au-dessus du métal nu, la perte d'une telle isolation lors de la migration vers un environnement avec des conteneurs orchestrés est inacceptable. Compte tenu de ces limites, ma thèse a été écrite et la police suédoise est considérée comme un client cible.
La problématique spécifique de l'étude considérée dans la thèse est:
Comment la démarcation des applications est-elle prise en charge dans Docker et Kubernetes par rapport aux machines virtuelles exécutées au-dessus de l'hyperviseur ESXi fonctionnant sur du métal nu?
Ce problème nécessite une étude approfondie. Pour commencer, regardez le dénominateur commun - les applications.
Les applications Web prêtent à confusion
Vulnérabilités dans les applications Web - un véritable zoo de vecteurs d'attaque. Les risques les plus importants sont présentés dans le Top 10 de l'OWASP (
2013 ,
2017 ). Ces ressources aident à éduquer les développeurs à réduire les risques typiques. Cependant, même si les développeurs ont écrit du code sans faille, l'application peut toujours être vulnérable - par exemple, grâce aux dépendances des packages.
David Gilbertson a écrit une
grande histoire sur la façon dont vous pouvez injecter du code via un package malveillant distribué, par exemple, dans le cadre de NPM pour les applications basées sur Node.js. Pour détecter les vulnérabilités, vous pouvez utiliser des scanners de dépendance, mais ils ne font que
réduire le risque, mais ne l'éliminent pas complètement.
Même si vous créez des applications sans dépendances tierces, il est toujours irréaliste de croire que l'application ne deviendra jamais vulnérable.
En raison de ces risques, nous ne pouvons pas dire que les applications Web sont sûres.Au lieu de cela, respectez une stratégie de
défense en profondeur (DID). Jetons un œil au niveau supérieur: les conteneurs et les machines virtuelles.
Conteneurs contre machines virtuelles - une histoire d'isolement
Un conteneur est un environnement d'espace utilisateur isolé qui est souvent implémenté en utilisant les capacités du noyau. Par exemple,
Docker utilise pour cela les espaces de noms, les groupes de contrôle et les capacités Linux. En ce sens, l'isolement des conteneurs Docker est
très différent des machines virtuelles lancées par des hyperviseurs de type 1
(c'est-à-dire travaillant directement sur le matériel; hyperviseurs nus) .
La différenciation pour de telles machines virtuelles peut être implémentée à un niveau aussi bas que dans le matériel réel, par exemple, via
Intel VT . Les conteneurs Docker, à leur tour, s'appuient sur le noyau Linux pour la démarcation. Cette différence est très importante à prendre en compte lorsqu'il s'agit d'
attaques en couches inférieures .
Si un attaquant est capable d'exécuter du code dans une machine virtuelle ou un conteneur, il peut potentiellement atteindre un niveau inférieur en effectuant une
attaque d'échappement .
selon que les conteneurs ou les machines virtuelles sont utilisés sur le matériel, la différenciation est mise en œuvre à différents niveaux d'infrastructure.La possibilité de telles attaques a été prouvée pour l'hyperviseur
VMware ESXi lors du concours de hacker Pwn2Own 2017, ainsi que pour GeekPwn2018. Le résultat a été une paire de
CVE (
CVE-2017–4902 ,
CVE-2018–6981 ) qui peuvent être utilisés dans les attaques de couche inférieure pour
quitter les machines virtuelles ( échappement de machine virtuelle ) . Les machines virtuelles sur serveurs de fer ne garantissent pas une sécurité absolue, même si elles utilisent la technologie pour différencier le niveau de fer.
D'un autre côté, si nous regardons les vecteurs d'attaque sur un hyperviseur nu-métal par rapport au noyau Linux, il est évident que ce dernier a une surface d'attaque beaucoup plus grande - en raison de sa taille [noyau Linux] et de sa gamme de capacités. Une surface d'attaque plus grande implique plus de vecteurs d'attaque potentiels pour les environnements cloud utilisant l'isolement des conteneurs. Cela se manifeste par l'attention croissante portée aux
attaques d'échappement de conteneurs , qui ont été rendues possibles grâce aux exploits du noyau (par exemple,
CVE-2016–5195 [c. -à- d. Dirty COW - approx. Transl.] ,
CVE-2017–1000405 )
Des modules comme
SELinux ou
AppArmor peuvent être utilisés pour augmenter l'isolation
à l'intérieur du conteneur. Malheureusement, de tels mécanismes de sécurité dans le noyau n'empêchent pas les attaques d'échappement sur le noyau lui-même. Ils ne limiteront les actions possibles de l'attaquant que si le dépassement des limites n'est
pas possible . Si nous voulons gérer les sorties à l'extérieur du conteneur, un mécanisme d'isolement
à l'extérieur du conteneur ou même du noyau
est nécessaire. Par exemple, un bac à sable
(bac à sable) !
gVisor est un sandbox pour le
runtime du conteneur, dont le code a été ouvert par Google et qui ajoute un noyau supplémentaire entre le conteneur et le noyau du système d'exploitation. Ce type de sandbox peut améliorer la situation avec des attaques de conteneurs hors limites qui ont lieu
au niveau du noyau . Cependant, les principaux exploits ne sont qu'un des outils de l'attaquant.
Pour voir comment d'autres attaques peuvent conduire à des résultats similaires, vous devez regarder une image plus générale de la façon dont les conteneurs sont utilisés à l'ère du cloud.
L'effet de l'orchestration des conteneurs sur l'isolement
Pour gérer les conteneurs s'exécutant dans des environnements avec de nombreux nœuds, ils introduisent l'orchestration, dans laquelle Kubernetes donne le rôle principal. Il s'avère que les bogues d'orchestrateur peuvent également affecter l'isolement des conteneurs.
Tim Allclair a
fait une merveilleuse présentation à KubeCon 2018, dans laquelle il a noté quelques surfaces d'attaque. Dans son rapport, il
mentionne un exemple (
CVE-2017-1002101 ), comment les bogues d'orchestration peuvent affecter l'isolement - dans ce cas, grâce à la possibilité de monter de l'espace disque en dehors du pod. Les vulnérabilités de ce type sont très problématiques, car peut contourner le bac à sable dans lequel le conteneur est emballé.
En introduisant Kubernetes, nous avons élargi la surface d'attaque. Il comprend des systèmes hébergés sur le maître Kubernetes. L'un d'eux est le serveur API Kubernetes, où ils ont récemment découvert une vulnérabilité qui pourrait autoriser
des privilèges
excessifs (
CVE-2018–1002105 ). Étant donné que la surface d'attaque du maître Kubernetes dépasse le cadre de ma thèse, cette vulnérabilité particulière n'est pas prise en compte.
Pourquoi les attaques par évasion sont-elles si importantes? Les conteneurs ont permis d'exécuter de nombreuses applications co-hébergées dans le même système d'exploitation. Il y avait donc un risque associé à l'isolement des applications. Si une application critique et une autre application vulnérable s'exécutent sur le même hôte, un attaquant pourrait accéder à une application critique via une attaque contre une application vulnérable.
Selon le type de données avec lesquelles l'organisation travaille, leur fuite peut nuire non seulement à l'organisation elle-même, mais également aux individus et à l'ensemble du pays. Comme vous vous en souvenez, nous parlons du secteur public, des finances, des banques ... - une fuite peut sérieusement affecter la vie des gens.
L'orchestration de conteneurs peut-elle même être utilisée dans de tels environnements? Avant d'entamer une réflexion plus approfondie, une évaluation des risques doit être effectuée.
Quel risque est acceptable?
Avant d'introduire des mesures de sécurité, il est important de réfléchir au type d'informations que l'organisation essaie réellement de protéger. La décision de savoir si des mesures supplémentaires sont nécessaires pour empêcher d'éventuelles attaques d'échappement sur les conteneurs dépend des données avec lesquelles l'organisation travaille et des services qu'elle fournit.
À long terme, cela signifie que pour obtenir la possibilité de quitter le conteneur sur un hôte
correctement configuré protégé par le sandbox du conteneur, l'attaquant doit:
- exécuter du code dans un conteneur, par exemple, par injection de code ou en utilisant des vulnérabilités dans le code d'application;
- profiter d'une autre vulnérabilité, zero-day, ou pour laquelle un correctif n'a pas encore été appliqué pour quitter le conteneur même s'il existe un sandbox .
Comme vous pouvez le deviner, une organisation qui ne considère pas un tel scénario comme acceptable devrait travailler avec des données ou offrir des services très exigeants en matière de
confidentialité , d'
intégrité et / ou d'
accessibilité .
Étant donné que la thèse est consacrée à de tels clients, la perte de l'isolement du système en sortant du conteneur n'est pas autorisée, car ses conséquences sont trop importantes. Quelles mesures peuvent être prises pour améliorer l'isolement? Pour monter d'un niveau dans l'échelle d'isolement, vous devez également regarder les bacs à sable dans lesquels le noyau du système d'exploitation est enveloppé, c'est-à-dire machines virtuelles!
Les technologies de virtualisation qui utilisent des hyperviseurs hébergés amélioreront la situation, mais nous voulons limiter
encore plus la surface d'attaque. Par conséquent, examinons les hyperviseurs installés sur le fer et voyons vers quoi ils nous mèneront.
Hyperviseurs sur le fer
Une
étude de l' Agence suédoise suédoise de recherche pour la défense a examiné les risques de virtualisation en relation avec les forces armées suédoises. Sa conclusion a parlé des avantages de ces technologies pour l'armée, même avec les exigences de sécurité strictes et les risques que la virtualisation apporte.
À cet égard, nous pouvons dire que la virtualisation est utilisée (dans une certaine mesure) dans l'industrie de la défense, car elle comporte
des risques acceptables . Étant donné que les agences et les entreprises de l'industrie de la défense sont l'un des clients les plus exigeants en matière de sécurité informatique, nous pouvons également affirmer que le risque acceptable pour eux signifie qu'il est acceptable pour les clients considérés dans la thèse. Et tout cela - malgré les sorties potentielles au-delà de la machine virtuelle, discutées ci-dessus.
Si nous décidons d'utiliser ce type de bac à sable pour les conteneurs, il y a quelques éléments à considérer dans le contexte des spécificités natives du cloud.
Noeuds sandbox pour machines virtuelles
L'idée est que les nœuds du cluster Kubernetes sont des machines virtuelles qui utilisent la virtualisation matérielle. Étant donné que les machines virtuelles joueront le rôle de sandbox pour les conteneurs qui s'exécutent dans des pods, chaque nœud peut être considéré comme un environnement protégé par sandbox.
Remarque importante à propos de ces bacs à sable dans le contexte des bacs à sable de conteneur déjà mentionnés: cette approche vous permet de placer plusieurs conteneurs dans un bac à sable. Cette flexibilité vous permet de réduire les frais généraux par rapport au cas où chaque conteneur a son propre bac à sable. Comme chaque sandbox apporte son propre système d'exploitation, nous voulons réduire leur nombre tout en maintenant l'isolement.
Les machines virtuelles installées sur le matériel - nœuds de cluster - agissent comme des sandbox pour les conteneurs. Les conteneurs s'exécutant sur différentes machines virtuelles sont délimités avec un niveau de risque acceptable. Cependant, cela ne s'applique pas aux conteneurs s'exécutant sur la même machine virtuelle.Cependant, étant donné que Kubernetes est capable de changer le placement des gousses pour diverses raisons, ce qui peut
ruiner l'idée d'utiliser des bacs à sable , il sera nécessaire d'ajouter des restrictions sur le mécanisme de placement des gousses communes. Vous pouvez atteindre le résultat souhaité de plusieurs manières.
Au moment de la rédaction, Kubernetes (
v1.13 ) prend en charge trois méthodes principales pour contrôler la planification et / ou le lancement des pods:
La ou les méthodes à utiliser dépendent de l'application de l'organisation. Cependant, il est important de noter que les méthodes diffèrent dans leur capacité à éliminer les pods après leur entrée dans la phase d'exécution. Maintenant, seules les souillures sont capables de cela - grâce à l'action
NoExecute . Si vous ne traitez pas ce moment de quelque façon que ce soit et que certaines étiquettes changent, tout peut entraîner une colocalisation indésirable.
Conformité aux exigences de colocalisation
La thèse propose l'idée d'utiliser un système de classification qui montre comment la sensibilité se reflète dans la colocalisation. L'idée est d'utiliser la relation 1: 1 entre le conteneur et le pod et de déterminer la colocalisation des pods en fonction de la classification des applications conteneurisées.
Pour plus de simplicité et de réutilisabilité, le système de classification en 3 étapes suivant est utilisé:
- Classe O : l'application n'est pas sensible et n'a pas d'exigences d'isolement. Il peut être placé sur tous les nœuds n'appartenant à aucune autre classe.
- Classe PG (groupe privé) : une application, avec un ensemble d'autres applications, forme un groupe privé pour lequel un nœud dédié est requis. Une application ne peut être hébergée que sur des nœuds de classe PG qui ont l'identifiant de groupe privé correspondant.
- Classe P (privée) : une application nécessite un nœud privé et séparé et ne peut être placée que sur des nœuds vides de sa classe (P).
Pour répondre aux exigences de colocalisation pour de nombreuses applications classifiées, des taches et des tolérances sont utilisées, avec lesquelles chaque nœud est affecté à une classe, et PodAffinity pour appliquer des restrictions supplémentaires pour les pods avec des applications de classe P ou PG.
Cet exemple simplifié montre comment les souillures et les tolérances peuvent être utilisées pour implémenter le contrôle de colocalisation:
Les pods 2 et 3 contiennent des applications d'un groupe privé, et l'application sur le pod 1 est plus sensible et nécessite un nœud dédié.Cependant, les classes P et PG nécessiteront des règles d'affinité supplémentaires pour garantir que les demandes de démarcation sont exécutées à mesure que le cluster et les applications hébergées se développent. Voyons comment vous pouvez implémenter
ces règles pour différentes classes:
# Class P affinity: podAntiAffinity: requiredDuringSchedulingIgnoredDuringExecution: - topologyKey: "kubernetes.io/hostname" namespaces: ["default"] labelSelector: matchExpressions: - key: non-existing-key operator: DoesNotExist
Les règles d'affinité pour les applications de classe P nécessitent des nœuds dédiés. Dans ce cas, le pod ne sera pas planifié si le pod se ferme sans
non-existing-key . Tout fonctionnera jusqu'à ce qu'un seul pod ait cette clé.
# Class PG affinity: podAffinity: requiredDuringSchedulingIgnoredDuringExecution: - topologyKey: "kubernetes.io/hostname" labelSelector: matchLabels: class-pg-group-1: foobar podAntiAffinity: requiredDuringSchedulingIgnoredDuringExecution: - topologyKey: "kubernetes.io/hostname" labelSelector: matchExpressions: - key: class-pg-group-1 operator: DoesNotExist
Pour les applications de classe PG, les règles d'affinité co-hébergent les pods qui ont un identifiant de groupe
class-pg-group-1 et sur les nœuds qui ont des pods sans identifiant.
Une telle approche nous permettra d'utiliser un système de classification pour délimiter les conteneurs en fonction des exigences pertinentes d'une application conteneurisée.
Qu'avons-nous obtenu?
Conclusion
Nous avons envisagé un moyen d'implémenter des bacs à sable basés sur l'hyperviseur de type 1 (c'est-à-dire lancé sur du métal nu) pour créer des nœuds dans les clusters Kubernetes et présenté un système de classification qui définit les exigences de délimitation des applications conteneurisées. Si nous comparons cette approche avec les autres solutions envisagées, elle présente des avantages en termes d’isolation du système.
Une conclusion importante est que la stratégie d'isolement
limite la propagation des attaques d'échappement au conteneur.
En d'autres termes, le fait de laisser le conteneur seul n'est pas empêché, mais ses effets sont atténués. De toute évidence, cela s'accompagne de difficultés supplémentaires qui doivent être prises en compte lors de comparaisons similaires.
Pour utiliser la méthode spécifiée dans un environnement cloud et fournir une évolutivité, des exigences supplémentaires seront imposées à l'automatisation. Par exemple, pour automatiser la création de machines virtuelles et leur utilisation dans le cluster Kubernetes. La chose la plus importante sera la mise en œuvre et la vérification de la classification
répandue des demandes.
Cela fait partie de ma thèse sur l'
isolement d'une application conteneurisée .
Pour éviter qu'un attaquant qui se déconnecte du conteneur sur un nœud n'attaque les services d'autres nœuds, il est nécessaire de considérer
les attaques propagées par le réseau . Pour prendre en compte ces risques, ma thèse propose une
segmentation du réseau de clusters et introduit des architectures cloud, dont l'une dispose d'un
pare-feu matériel .
Ceux qui le souhaitent peuvent se familiariser avec le document complet - le texte de la thèse est accessible au public: «
Container Orchestration in Security Demanding Environments at the Swedish Police Authority ».
PS du traducteur
Lisez aussi dans notre blog: