Tout dépends si tous ces services utilisent le même jeu de données ou pas.
Parce qu'au final c'est ce qui nous intéresse, qu'un attaquant ou un client ne puisse pas accéder à ce qu'il n'a pas le droit. Si tu sépares tes n services mais qu'il y en a un qui a un bug ou une faille importante mais que tous accèdent à la mėme DB, ça ne change pas grand chose que ces services soient plus strictement isolés les uns des autres.
Bref architecture toussa.
À part ça utiliser des containers et l'isolation par vm, ce ne sont pas des sujets incompatibles. Il faut en prendre en compte les limitations mais c'est à ça que servent des projets comme katacontainers par exemple.
Et pourquoi s'arrêter aux VM? Il ya a des projets qui laissent le choix à leur client entre une offre moins chère et multitenant avec une offre single-tenant tournant dans un compte "cloud" dedié.
[^] # Re: containers
Posté par Psychofox (Mastodon) . En réponse au journal Sécurité de linux. Évalué à 3. Dernière modification le 10 juin 2025 à 08:21.
Tout dépends si tous ces services utilisent le même jeu de données ou pas.
Parce qu'au final c'est ce qui nous intéresse, qu'un attaquant ou un client ne puisse pas accéder à ce qu'il n'a pas le droit. Si tu sépares tes n services mais qu'il y en a un qui a un bug ou une faille importante mais que tous accèdent à la mėme DB, ça ne change pas grand chose que ces services soient plus strictement isolés les uns des autres.
Bref architecture toussa.
À part ça utiliser des containers et l'isolation par vm, ce ne sont pas des sujets incompatibles. Il faut en prendre en compte les limitations mais c'est à ça que servent des projets comme katacontainers par exemple.
Et pourquoi s'arrêter aux VM? Il ya a des projets qui laissent le choix à leur client entre une offre moins chère et multitenant avec une offre single-tenant tournant dans un compte "cloud" dedié.