L'argument principal utilisé pour conseiller les conteneurs plutôt que les machines virtuelles (qui me semblent clairement plus sécurisées) est qu'avec les machines virtuelles c'est à l'utilisateur de maintenir son noyau à jour question sécurité, alors qu'avec les conteneurs il ne choisit pas le noyau et c'est le fournisseur de service qui le maintient, et le maintient sans doute mieux.
Cet argument me semble bancal. On pourrait utiliser exactement le même pour dire que les machines partagées sont plus sécurisées en moyenne que les machines où l'utilisateur contrôle tout, et pourtant l'auteur ne les conseille pas.
L'analyse repose sur l'idée que la maintenance du système est assurée soit par le fournisseur, bien, soit par l'utilisateur, mal. Même si on ne suppose pas que les utilisateurs compétents et dévoués sont majoritaires, on peut aussi remarquer qu'il existe des tierces parties qui peuvent se charger de maintenir des morceaux de la stack pour l'utilisateur. Le fournisseur peut le faire dans certains schémas, mais on peut aussi compter sur une distribution pour maintenir un kernel, ou sur un fournisseur de machines virtuelles (par exemple Red Hat fournit des conteneurs de base dans lequel on peut déployer ses applications, remplaçant une partie du rôle du fournisseur). On peut avoir des tiers à qui on fait aussi ou plus confiance qu'au fournisseur de machines pour la maintenance de sécurité.
Il me semble qu'il y a deux choses à dire :
Pour un utilisateur non-expert, le mieux est d'avoir le moins d'opérations de maintenance à faire possibles, en déléguant la plus grande partie de la pile applicative à des tiers de confiance. Mais pas forcément le fournisseur ! On peut tout à fait louer les services d'un fournisseur qui déploie des machines virtuelles (sur un hyperviseur, donc), et utiliser un fournisseur tiers de machines virtuelles en qui on a confiance pour configurer et maintenir le kernel. On peut aussi utiliser une distribution en qui on a confiance pour configurer et maintenir la grande majorité de la couche applicative—le plus possible.
Pour un fournisseur de machines qui ne veut pas fournir de machines dédiées (trop cher), l'interface la plus protégée du code des utilisateurs est un hyperviseur—tant qu'on en prend plus petit et plus simple que le kernel Linux, et plus attentif à la sécurité. Il peut bien sûr proposer une interface au-dessus à ses clients, par exemple "conteneurs" ou même "login sur une machine partagée" (ou déploiement clicodrome d'applications fixées à l'avance), mais il a intérêt à construire ça au-dessus de machines virtuelles séparées s'il veut limiter au maximum les risques d'attaques d'un utilisateur à l'autre. (Bien sûr, un gain en sécurité peut avoir un coût en performance.)
# Pas convaincant
Posté par gasche . En réponse au journal Surface d'attaque des serveurs dans les nuages (cloud). Évalué à 6.
L'argument principal utilisé pour conseiller les conteneurs plutôt que les machines virtuelles (qui me semblent clairement plus sécurisées) est qu'avec les machines virtuelles c'est à l'utilisateur de maintenir son noyau à jour question sécurité, alors qu'avec les conteneurs il ne choisit pas le noyau et c'est le fournisseur de service qui le maintient, et le maintient sans doute mieux.
Cet argument me semble bancal. On pourrait utiliser exactement le même pour dire que les machines partagées sont plus sécurisées en moyenne que les machines où l'utilisateur contrôle tout, et pourtant l'auteur ne les conseille pas.
L'analyse repose sur l'idée que la maintenance du système est assurée soit par le fournisseur, bien, soit par l'utilisateur, mal. Même si on ne suppose pas que les utilisateurs compétents et dévoués sont majoritaires, on peut aussi remarquer qu'il existe des tierces parties qui peuvent se charger de maintenir des morceaux de la stack pour l'utilisateur. Le fournisseur peut le faire dans certains schémas, mais on peut aussi compter sur une distribution pour maintenir un kernel, ou sur un fournisseur de machines virtuelles (par exemple Red Hat fournit des conteneurs de base dans lequel on peut déployer ses applications, remplaçant une partie du rôle du fournisseur). On peut avoir des tiers à qui on fait aussi ou plus confiance qu'au fournisseur de machines pour la maintenance de sécurité.
Il me semble qu'il y a deux choses à dire :
Pour un utilisateur non-expert, le mieux est d'avoir le moins d'opérations de maintenance à faire possibles, en déléguant la plus grande partie de la pile applicative à des tiers de confiance. Mais pas forcément le fournisseur ! On peut tout à fait louer les services d'un fournisseur qui déploie des machines virtuelles (sur un hyperviseur, donc), et utiliser un fournisseur tiers de machines virtuelles en qui on a confiance pour configurer et maintenir le kernel. On peut aussi utiliser une distribution en qui on a confiance pour configurer et maintenir la grande majorité de la couche applicative—le plus possible.
Pour un fournisseur de machines qui ne veut pas fournir de machines dédiées (trop cher), l'interface la plus protégée du code des utilisateurs est un hyperviseur—tant qu'on en prend plus petit et plus simple que le kernel Linux, et plus attentif à la sécurité. Il peut bien sûr proposer une interface au-dessus à ses clients, par exemple "conteneurs" ou même "login sur une machine partagée" (ou déploiement clicodrome d'applications fixées à l'avance), mais il a intérêt à construire ça au-dessus de machines virtuelles séparées s'il veut limiter au maximum les risques d'attaques d'un utilisateur à l'autre. (Bien sûr, un gain en sécurité peut avoir un coût en performance.)