Full Circle Magazine FR

Cette page est en lecture seule. Vous pouvez afficher le texte source, mais ne pourrez pas le modifier. Contactez votre administrateur si vous pensez qu'il s'agit d'une erreur.
**There are a number of areas to keep in mind when it comes to securing containers that you have running on your Ubuntu hosts and their workloads. In this article, we’ll have a look at a high-level overview of the key things to bear in mind. We’ll start with a more traditional security approach first and then focus on some of the other pertinent aspects.

Host Security

If you’re completely embroiled with getting your containers running just as you’d like them to, then it’s easy to overlook the fact that you should firstly pay close attention to the host machine that those containers are running on. Clearly the security of the host that your containers are relying upon determines how much uptime you will achieve for your applications and additionally affect the number of threats that might cause issues for you.

The usual rules apply when it comes to your host machines. You will need to update packages when they become available, most likely schedule reboots for kernel updates and also ensure that a minimal number of packages are installed to help limit the attack surface.

Aside from the time-honoured package updates, you should ensure that only specific network ports are exposed, locally and publicly, and then firewall off all other points of network access. Where possible, rate limiting access to applications, and monitoring accesses via public network ports in detail, is also advised.**

Il faut garder à l'esprit de nombreuses choses quand il s'agit de sécuriser les conteneurs qui tournent sur vos hôtes Ubuntu et leur charge de travail. Dans cet article, je vous donnerai un aperçu de haut niveau des éléments clés dont il faut en tenir compte. Nous commencerons avec une approche sécuritaire traditionnelle, puis je me concentrerai sur certains des autres aspects pertinents.

La sécurité de l'hôte

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 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 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

Another area can be helped significantly with a smattering of common sense and logic.

Imagine for example that you have three containers running on a single host, each with a unique application that provides a service of some sort. It’s advisable to carefully consider how those containers might interact from an architectural standpoint. If Container A passes data to only Container B, then Container C doesn’t need access to Container A directly at all and should be isolated at both a host and an internal networking level.

Consider another scenario where you might have two upfront web servers running via two containers, and additionally a single backend database server. The front-end servers pass read and write requests back to the database and only TCP port 443 needs to be exposed to the public from a network perspective. 

There are however lots of other containers running on the same host machine which shouldn’t have any visibility of the potentially sensitive database traffic being passed through the database server before being written and stored outside of the container. The recommendation here would be to use a bridge network. By connecting only our two web servers and single database server to that private network, we will successfully limit network access and provide a layer of isolation.

This means that if another container on the host is attacked and compromised there’s more layers of security potentially for the attacker to break through in order to get access to the database data.**

Limiter la diaphonie

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 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 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é 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é à franchir par un attaquant pour avoir accès aux données de la base de données.

**Common Vulnerabilities

The dreaded CVEs (Common Vulnerabilities and Exploits) apply to package updates just as we saw on a host’s Operating System a moment ago and you should monitor CVEs using any of a variety of tools.

How you approach updating packages inside your containers is a different matter. There are a number of valid approaches but a strategy is definitely required and often dismissed as being trivial. As a result, ad hoc patching practices can become dangerously erratic. This is because even the very popular container images hold a surprising number of CVEs at the best of times. Indeed many packages don’t have fixes available from the vendor at the time that a container is spun up and potentially exposed publicly meaning patching is near to impossible.

The recommendation is to think carefully about what risks affect you the most. Take time to fully understand your priorities and the attack surfaces that you present inwardly and externally. Then think about how realistic updating every package for triggered alerts is and at what frequency. Choosing a tool which can automatically alert you to software updates can be a little daunting as there are a few. One such sophisticated tool which can run from containers itself can be found here (https://anchore.com/opensource) and is called Anchore.

As mentioned, not all issues with CVEs can be mitigated against using package manager updates because fixes haven’t been released by vendors. Trade-offs between using alternative base Operating Systems and using alternative applications might be required on occasion.**

Les vulnérabilités communes

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.

The Linux kernel has introduced a number of clever isolation techniques over the years which we won’t look at in detail here. 

You should be aware of Kernel Namespaces, however, which means Customer A can’t see what Customer B is doing if all goes well from a security perspective. Additionally, you should know about Control Groups, known as “cgroups”, which can apply strict resource quotas such as how much memory or disk access a container might be allowed.

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.**

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.

Many people turn to Kubernetes (https://kubernetes.io) for larger workloads, and this brings its own security considerations in addition.

In brief you should use a more sophisticated approach to network isolation than we looked at earlier, and ensure customers or applications are split up by namespaces.

You should also finely tune Pod Security Policies, which are cluster-wide, to limit crosstalk noise and additionally host access.

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.**

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.**

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.**

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.