Différences

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

--- issue153:mon_opinion1 [2020/02/04 11:14] – auntiee
+++ issue153:mon_opinion1 [2020/02/04 19:24] (Version actuelle) – d52fr
@@ Ligne 13: / Ligne 13: @@
 La sécurité de l'hôte
-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.
+Si vous êtes complètement occupé à 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 la sécurité de l'hôte sur lequel vos conteneurs comptent 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 replanifier 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 un nombre minimal de paquets soient installé pour limiter la surface d'attaque.
-Outre les mises à jour des paquets, bien connues, vous devraiez vous assusrer que uniquement des 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.
+Outre les mises à jour des paquets, bien connues, vous devriez vous assurer que seuls des 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 de surveiller dans le détail les accès via des ports publics du réseau.
 **Limiting Crosstalk
@@ Ligne 35: / Ligne 35: @@
 La sécurité d'un autre domaine peut être prise en charge de façon significative avec un peu de sens commun et de la logique.
-Supposez, par exemple, que vous avez trois conteneurs sur un seul hôte, chacun avec une application unique qui fournit un service quelconque. Je vous conseille de réflechir soigneusement à la façon dont ces conteneurs pourraient interagir du point de vue de l'architecture. Si le Conteneur A n'envoie des données qu'au Conteneur B, le Conteneur C n'a pas du tout besoin d'un accès direct au Conteneur A et devrait être isolé à la fois au niveau de l'hôte et au niveau du réseau interne.
+Supposez, par exemple, que vous ayez trois conteneurs sur un seul hôte, chacun avec une application unique qui fournit un service quelconque. Je vous conseille de réfléchir soigneusement à la façon dont ces conteneurs pourraient interagir du point de vue de l'architecture. Si le Conteneur A n'envoie des données qu'au Conteneur B, le Conteneur C n'a pas du tout besoin d'un accès direct au Conteneur A et devrait être isolé à la fois au niveau de l'hôte et au niveau du réseau interne.
-Examinons un autre sénario où vous pourriez avoir deux serveurs Web en avant-plan qui tournent grâce à deux conteneurs et, aussi, un seul serveur de données en arrière-plan. Les serveurs en avant-plan envoie des requêtes re lecture et de l'écriture à la base de données et le TCP port 443 est le seul qui doit être exposé au public de la perspective du réseau.
+Examinons un autre scénario où vous pourriez avoir deux serveurs Web en avant-plan qui tournent grâce à deux conteneurs et, aussi, un seul serveur de données en arrière-plan. Les serveurs en avant-plan envoient des requêtes de lecture et d'écriture à la base de données et le port 443 TCP est le seul qui doit être exposé au public vu du réseau.
-Il y a cependant des foules d'autres conteneurs qui tournent sur la même machine hôte qui ne devraient avoir aucune visibilité du traffic potentiellement sensible passant au travers du serveur de la base de données avant d'être écrit et stocké en dehors du conteneur. Ici, je conseillerais d'utiliser un réseau de passerelles. En connectant  seulement les deux serveurs Web et l'unique serveur de la base de données à ce réseau privé, nous réussirons à limiter l'accès réseau et fournirons une couche d'isolation.
+Il y a cependant des foules d'autres conteneurs qui tournent sur la même machine hôte qui ne devraient avoir aucune visibilité sur le trafic potentiellement sensible passant au travers du serveur de la base de données avant d'être écrit et stocké en dehors du conteneur. Ici, je conseillerais d'utiliser un réseau à passerelles. En connectant  seulement les deux serveurs Web et l'unique serveur de la base de données à ce réseau privé, nous réussirons à limiter l'accès réseau et fournirons une couche d'isolation.
-Cela signifie que, si un autre conteneur sur l'hôte est attaqué et compromis, il y a plus de couches de sécurité qu'un attaquant devrait franchir pour avoir accès aux données de la base de données.
+Cela signifie que, si un autre conteneur sur l'hôte est attaqué et compromis, il y a plus de couches de sécurité à franchir par un attaquant pour avoir accès aux données de la base de données.
 **Common Vulnerabilities
@@ Ligne 55: / Ligne 55: @@
 Les vulnérabilités communes
-Locking Down Access
+Les CVE (Common Vulnerabilities and Exploits) tant redoutés s'appliquent aux mises à jour de paquets, comme nous venons de le voir sur le système d'exploitation de l'hôte et vous devriez surveiller les CVE avec divers outils.
+L'approche de la mise à jour de paquets dans vos conteneurs est tout à fait autre chose. Un nombre d'approches convenables existent, mais il vous faut une stratégie qui, pourtant, est souvent rejetée comme étant anodine. Ainsi, les pratiques de correctifs ad hoc peuvent devenir dangereusement erratiques, parce que même les images très populaires de conteneur contiennent au mieux un nombre étonnant de CVE. En fait, les vendeurs ne rendent pas toujours disponibles les correctifs pour beaucoup de paquets au moment où un conteneur est créé et potentiellement exposé au public, ce qui signifi qu'appliquer des correctifs est presque impossible.
+La recommandation est de bien réfléchir aux risques qui vous affectent le plus. Prenez le temps de comprendre pleinement vos priorités ainsi que les surfaces d'attaque que vous présentez en interne comme en externe. Ensuite, décidez dans quelle mesure la mise à jour de chaque paquet pour des alertes déclenchées est réaliste et à quelle fréquence. Choisir un outil qui peut vous alerter automatiquement des mises à jour de logiciels peut être décourageant, car il n'y en a que quelques-uns. Un outil sophistiqué, qui peut tourner à l'intérieur des conteneurs, s'appelle Anchore et se trouve ici (https://anchore.com/opensource).
+Comme mentionné tous les problèmes des CVE ne peuvent pas être mitigés en utilisant les mises à jour proposées par le gestionnaire des paquets, parce que les correctifs n'ont pas été publiés par les vendeurs. Des compromis entre l'utilisation de systèmes d'exploitations alternatifs et l'utilisation d'applications alternatives peuvent s'avérer nécessaire de temps en temps.
+**Locking Down Access
 As all containers share the same host kernel on a machine, it’s imperative that suitable isolation is put in place to protect the host. Without the host functioning correctly, ultimately there’s only downtime which means failure to stop a successful attack on one container from performing a “container escape” will mean that other containers, and their applications, or even the host itself, might succumb to the attack.
@@ Ligne 65: / Ligne 73: @@
 You might want to also read up on Kernel Capabilities – which can achieve all sorts of useful access restrictions. For example, do you really want a container to be able to change the time and date on your host’s system clock? It’s unlikely!
-Although we’ve just scratched the surface on this topic, you should also make sure that lesser privileged users can’t start and stop containers with permissions that an attacker can do bad things with. Leave that sort of thing to the “root” superuser alone.
+Although we’ve just scratched the surface on this topic, you should also make sure that lesser privileged users can’t start and stop containers with permissions that an attacker can do bad things with. Leave that sort of thing to the “root” superuser alone.**
-Orchestration
+Verrouiller l'accès
+Puisque tous les conteneurs sur une même machine partage le noyau de l'hôte, il est essentiel pour sa protection que l'hôte soit convenablement isolé. Si l'hôte ne fonctionne pas correctement, à la longue il n'y a que des temps d'arrêt ce qui signifie qu'une attaque réussie sur un conteneur n'est pas empêchée et que celui-là peut « s'évader », ce qui, à son tour, signifiera que les autres conteneurs, et leurs applications, ou même l'hôte lui-même, pourraient succomber à l'attaque.
+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 (espaces de noms), qui signifient que, si tout se passe bien d'une perspective sécuritaire, le Client A ne peut pas voir ce que fait le 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 qu'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 devriez 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 lesquelles un assaillant pourrait faire de vilaines choses. Laissez ce genre de chose au super-utilisateur root seul.
+**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 79: / 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 grosses charges de travail, beaucoup de gens font appel à Kubernetes (https://kubernetes.io), qui apporte ses propres considérations sécuritaires en plus.
+Bref, vous devriez utiliser une approche de l'isolation du réseau plus sophistiquée que celle traitée ci-dessus, et vous assurer que les clients ou les applications sont divisés par des namespaces.
+Vous devriez également affiner les Pod Security Policies (Règles de sécurisation des Pods), qui sont valables sur tout l'ensemble, pour limiter le bruit de la diaphonie et, en plus, l'accès à l'hôte.
+Enfin, pour les scénarios des conteneurs sensibles, vous pouvez introduire les Security Context Constraints (Contraintes contextuelles de sécurité) (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/), le runtime de conteneur de 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 virtuelles adoptent 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 effleuré 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 sécurité des conteneurs.