Différences

Ci-dessous, les différences entre deux révisions de la page.

--- issue153:mon_opinion1 [2020/02/04 12:05] – auntiee
+++ issue153:mon_opinion1 [2020/02/04 15:08] – auntiee
@@ Ligne 15: / Ligne 15: @@
 Si vous êtes complètement occupé en essayer de faire tourner vos conteneurs exactement comme vous voulez, il est facile d'oublier le fait que vous devriez d'abord accorder une attention particulière à la machine hôte sur laquelle ces conteneurs-là tournent. Il est évident que les sécurité de l'hôte sur lequel comptent vos conteneurs détermine combien de temps actif vous aurez pour les applications et, de plus, affecte le nombre de menaces qui pourrait vous causer des problèmes.
-Les règles habituelles s'appliquent quand il s'agit de vos machines hôte. Vous devrez mettre à jour les paquets dès la disponibilité d'une mise à jour, probablement replannifier les redémarrages pour les mises à jour du noyaut et également vous assurer que nombre minimal de paquets soient installé pour limiter la surface d'attaque.
+Les règles habituelles s'appliquent quand il s'agit de vos machines hôte. Vous devrez mettre à jour les paquets dès la disponibilité d'une mise à jour, probablement planifier les redémarrages pour les mises à jour du noyau et également vous assurer que nombre minimal de paquets soient installé pour limiter la surface d'attaque.
 Outre les mises à jour des paquets, bien connues, vous devriez vous assurer que des seuls ports réseaux spécifiques soient exposés, localement et publiquement, puis mettre un pare-feu sur tous les autres points d'accès à un réseau. Là où c'est possible, je vous conseille de limiter l'accès aux applications et surveiller dans le détail les accès via des ports réseau publics.
@@ Ligne 81: / Ligne 81: @@
 Au fil des ans, le noyau Linux a introduit de nombreuses techniques astucieuses d'isolation que nous n'examinerons pas en détail ici.
-Toutefois, vous devriez connaître les Kernel Namespaces, qui signifient que, si tout se passe bien d'une perspective sécuritaire, Client A ne peut pas voir ce ue fait Client B. De plus, vous devriez connaître les Control Groups,
+Toutefois, vous devriez connaître les Kernel Namespaces, qui signifient que, si tout se passe bien d'une perspective sécuritaire, Client A ne peut pas voir ce ue fait Client B. De plus, vous devriez connaître les Control Groups, alias « cgroups », qui peuvent appliquer des quotas stricts de ressources comme la quantité de mémoire ou d'accès au disque un conteneur pourrait avoir.
+Vous voudriez sans doute lire aussi quelque chose sur les capacités du noyau, car il peut créer toutes sortes de restrictions d'accès utiles. Par exemple, voulez-vous vraiment qu'un conteneur puisse changer la date et l'heure sur l'horloge système de l'hôte. C'est très peu probable !
+Bien que nous n'ayons fait qu'effleurer la surface de ce sujet, vous devraiez aussi vous assurer que des utilisateurs avec moins de privilèges ne puissent pas démarrer et arrêter des conteneurs avec des permissions, avec lesquels un assaillant pourrait faire de vilaines choses. Laissez ce genre de chose au super-utilisateur root seul.
-Orchestration
+**Orchestration
 When you’re running more than a few containers at once, it can be a little like herding cats trying to get them all to behave properly.
@@ Ligne 97: / Ligne 100: @@
 Finally for sensitive container scenarios, you can introduce Security Context Constraints (https://kubernetes.io/docs/tasks/configure-pod-container/security-context/) on a per Pod (one or more containers) basis.
-You’re encouraged to read further in order to get cluster security working well, amongst a number of other areas.
+You’re encouraged to read further in order to get cluster security working well, amongst a number of other areas.**
-Stronger Isolation
+Orchestration
+Quand vous faites tourner plus que quelques conteneurs à la fois, cela pourrait être comme essayer de rassembler des chats et de les faire bien se comporter.
+Pour de grandes charges de travail, beaucoup de gens font appelle à Kubernetes (https://kubernetes.io) et cela apporte ses propres considérations sécuritaires en plus.
+Bref, vous devriez utiliser une approche plus sophistiquée à l'isolation du réseau que nous avons traité ci-dessus, et vous assurer que les clients ou les applications sont divisées par des namespaces.
+Vous devriez également affiner les politiques Pod Security Polisies, quisont valable sur tout l'ensemble, pour limiter le bruit de la diaphonie et l'accès à l'hôte en plus.
+Enfin, pour des scénarios des conteneurs sensibles, vous pouvez introduire Security Context Constraints (https://kubernetes.io/docs/tasks/configure-pod-container/security-context/) sur la base d'une Pod (un ou plusieurs conteneurs).
+N'hésitez pas à en lire davantage afin de faire en sorte que la sécurité d'un ensemble fonctionne bien, parmi d'autres domaines.
+**Stronger Isolation
 Despite a very high level of isolation being possible through a previous Virtual Machine incarnation of “rkt” (https://coreos.com/rkt/), the container runtime by CoreOS using KVM (https://www.linux-kvm.org/page/Main_Page), all the rage currently is Kata Containers (https://katacontainers.io/). Essentially, Kata Containers’ aim is to provide Virtual Machine levels of security protection (where true host and workload isolation takes place), and allowing containers to benefit from such protection.
-Virtual Machines adopt a hardware level of isolation making attacks much, much harder than just circumventing a host machine’s kernel. By cleverly enforcing that level of isolation, but enjoying the quick start-up times, portability, and predictability of disposable containers, it is certainly a technology to pay close attention to. Stay tuned.
+Virtual Machines adopt a hardware level of isolation making attacks much, much harder than just circumventing a host machine’s kernel. By cleverly enforcing that level of isolation, but enjoying the quick start-up times, portability, and predictability of disposable containers, it is certainly a technology to pay close attention to. Stay tuned.**
-The End Is Nigh
+Une isolation plus forte
+Bien qu'un très haut niveau d'isolation soit possible grâce à l'incarnation en machine virtuelle précédente de « rkt » (https://coreos.com/rkt/), l'exécution de conteneur par CoreOS avec KVM (https://www.linux-kvm.org/page/Main_Page), ce qui est à la mode actuellement, c'est Kata Containers (https://katacontainers.io/). L'objectif de Kata Containers est essentiellement de fournir les mêmes niveaux de protection sécuritaire que les machines virtuelles (où une véritable isolation entre l'hôte et la charge de travail a lieu), et de permettre aux conteneurs de bénéficier d'une telle protection.
+Les machines viruelles acopte une isolation au niveau du matériel ce qui rend les attaques bien plus difficiles que le contournement tout simple du noyau de la machine hôte. En imposant astucieusement ce niveau-là d'isolation, mais avec des temps de démarrage rapide, la portabilité et la prédictabilité de conteneurs jetables, c'est certainement une technologie qui mérite votre attention. Restez en contact.
+**The End Is Nigh
 We’ve barely scratched the surface in terms of getting into the detail about securing applications in your containers.
-Hopefully, however, the key areas which we’ve looked at briefly will give you some food for thought about what to read up on further the next time you need to make a decision about how to approach solving a container security problem.
+Hopefully, however, the key areas which we’ve looked at briefly will give you some food for thought about what to read up on further the next time you need to make a decision about how to approach solving a container security problem.**
+La fin approche
+On n'a à peine effleurer la surface en termes d'approfondissement des détails sur la sécurisation des applications dans vos conteneurs.
+Cependant, j'espère que les domaines clés dont je vous ai donné un aperçu vous feront réfléchir autour de vos lectures la prochaine fois que vous devriez prendre une décision sur comment résoudre un problème de la sécurité des conteneurs.