BT

Votre opinion compte! Merci de bien vouloir répondre au sondage InfoQ!

Exécuter des Conteneurs Docker en toute Sécurité en Production

| par Hrishikesh Barua Suivre 5 Abonnés , traduit par Nicolas Frankel Suivre 3 Abonnés le 19 déc. 2016. Durée de lecture estimée: 3 minutes |

Une note à nos lecteurs : Suite à vos retours, nous avons développé un ensemble de fonctionnalités qui vous permettent de réduire le bruit, tout en ne perdant pas de vue ce qui est important. Recevez des notifications en ligne et par e-mail en choisissant les sujets qui vous intéressent.

Une manière de renforcer les conteneurs Docker en production est de les rendre immuables, c'est-à-dire en lecture seule. D'autres méthodes afin d'exécuter des conteneurs sécurisés comprennent la minimisation de la surface d'attaque et l'application de procédures de renforcement standard Linux ainsi que celles qui sont spécifiques à un environnement de conteneurs.

Un conteneur peut être exécuté en mode lecture seule en passant l'option --read-only au démarrage. Cela empêche tout processus d'écriture sur le système de fichiers. Toute tentative d'écriture entraîne une erreur. L'exécution de telles infrastructures immuables est également en lien avec d'autres bonnes pratiques pour les pipelines de déploiement logiciel.

Alors que l'immutabilité empêcherait l'exécution de scripts malveillants et des changements qui pourraient se produire par l'intermédiaire de vulnérabilités présentes dans d'autres logiciels fonctionnant à l'intérieur du conteneur, dans quelle mesure un tel mode est-il réalisable pour les applications du monde réel ? Par exemple, les applications qui génèrent des fichiers de trace et utilisent une base de données nécessitent des écritures.

Une solution possible pour l'écriture des traces serait d'utiliser un système de journalisation centralisé comme Elasticsearch/Logstash/Kibana (ELK) afin que tous les journaux soient collectés dans un endroit central, éventuellement un autre conteneur, qui ne soit pas directement accessible par l'utilisateur final. Une autre alternative consiste à exporter les journaux hors du conteneur en utilisant l'indicateur --log-driver lors du démarrage du conteneur. Pour les applications qui ont besoin d'un accès en écriture aux répertoires temporaires comme / tmp, une solution consiste à monter un système de fichier temporaire dans le conteneur pour ces répertoires.

Les bases de données ne sont pas directement accessibles par l'utilisateur final, donc le risque est plus faible. Cependant, cela n'empêche pas les attaques, à moins que les applications orientées utilisateur ne soient renforcées.

Dans les cas où il est inévitable d'avoir un système de fichiers accessible en écriture, Docker fournit l'audit et l'annulation des changements. Le système de fichiers dans un conteneur Docker est empilé comme une série de couches. Lorsqu'un nouveau conteneur est créé, un nouveau calque accessible en écriture est ajouté par dessus. Le pilote de stockage Docker le masque et le présente comme un système de fichiers standard à l'utilisateur. Les écritures réalisées dans un conteneur courant sont faites dans cette nouvelle couche. C'est généralement appelé Copy-On-Write (COW).

L'écart de configuration, ou les modifications de la configuration attendue, sont faciles à détecter dans un conteneur Docker. La commande 'docker diff' montre les modifications apportées au système de fichiers - qu'il s'agisse de fichiers ajoutés, supprimés ou modifiés.

En plus d'exécuter un conteneur en lecture seule si possible, d'autres recommandations pour la sécurisation des conteneurs en production sont :

  • L'exécution d'une image minimale comme Alpine Linux, qui a été conçue avec la sécurité comme objectif. Le noyau est patché avec un portage non officiel de grsecurity. Grsecurity est un ensemble d'améliorations de sécurité pour le noyau Linux qui inclut le contrôle d'accès et l' élimination des vulnérabilités basées sur la corruption de mémoire en minimisant les manières dont un système peut être attaqué.
  • La limitation des ressources (CPU/RAM) pour empêcher les attaques DdS.
  • La configuration des limites de thread et de processus dans le système d'exploitation.
  • L'application des procédures standard de renforcement du noyau Linux comme le renforcement sysctl.
  • L'exécution d'une application unique par conteneur. C'est recommandé car cela réduit la surface d'attaque, c'est-à-dire que la quantité de vulnérabilités possibles pour un conteneur donné est limitée à celles qui pourraient être présentes dans l'application dans ce conteneur.

Evaluer cet article

Pertinence
Style

Bonjour étranger!

Vous devez créer un compte InfoQ ou cliquez sur pour déposer des commentaires. Mais il y a bien d'autres avantages à s'enregistrer.

Tirez le meilleur d'InfoQ

Donnez-nous votre avis

Html autorisé: a,b,br,blockquote,i,li,pre,u,ul,p

M'envoyer un email pour toute réponse à l'un de mes messages dans ce sujet
Commentaires de la Communauté

Html autorisé: a,b,br,blockquote,i,li,pre,u,ul,p

M'envoyer un email pour toute réponse à l'un de mes messages dans ce sujet

Html autorisé: a,b,br,blockquote,i,li,pre,u,ul,p

M'envoyer un email pour toute réponse à l'un de mes messages dans ce sujet

Discuter

Se connecter à InfoQ pour interagir sur ce qui vous importe le plus.


Récupérer votre mot de passe

Follow

Suivre vos sujets et éditeurs favoris

Bref aperçu des points saillants de l'industrie et sur le site.

Like

More signal, less noise

Créez votre propre flux en choisissant les sujets que vous souhaitez lire et les éditeurs dont vous désirez suivre les nouvelles.

Notifications

Restez à jour

Paramétrez vos notifications et ne ratez pas le contenu qui vous importe

BT