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.