Alors que de plus en plus d’entreprises adoptent une culture DevOps, l’adoption de conteneurs se généralise pour devancer les pratiques traditionnelles basées sur le cloud. Selon les résultats de la dernière enquête du CNCF, 44 % des personnes interrogées utilisent déjà des conteneurs pour la quasi-totalité de leurs applications et segments d’activité. Parmi les répondants, 35 % déclarent utiliser des conteneurs pour certaines applications de production au sein de leur organisation, et 9 % se trouvent à un stade préliminaire d’adoption. En d’autres termes, elles pilotent et évaluent activement l’utilisation de conteneurs.
Adoption de conteneurs Docker
Les conteneurs Docker ont révolutionné la manière dont les développeurs créent, déploient et gèrent les applications. Capables d’offrir une solution légère et portable pour la création, la réalisation de tests et le déploiement de logiciels, ils ont vu leur popularité grimper en flèche. Mais, comme n’importe quel composant logiciel, les conteneurs Docker présentent des vulnérabilités aux attaques. L’utilisation de certificats SSL/TLS représente l’une des méthodes les plus efficaces pour renforcer la sécurité de ces conteneurs Docker.
Les certificats SSL/TLS sont largement utilisés pour chiffrer les flux de données sur les réseaux, qu’ils soient privés ou publics. Et pour ce qui est des conteneurs Docker, les certificats SSL/TLS garantissent la sécurité des éléments suivants :
- Communication entre le démon Docker et le client
- Communication entre les conteneurs Docker
- Communication entre les hôtes Docker
Architecture de l’hôte Docker. Source de l’image : docs.docker.com
Sécurisation de la communication entre le démon Docker et le client à l’aide de certificats TLS
Visualisation de l’architecture de Docker. Image: nickjanetakis.com
Le démon Docker est chargé de superviser la gestion des conteneurs et des images Docker. Il utilise un socket réseau pour détecter les requêtes émises par les clients Docker. Lorsqu’un client Docker envoie une requête au démon, il doit s’authentifier pour avoir l’autorisation d’effectuer l’opération demandée. L’utilisation de certificats SSL/TLS permet d’authentifier de manière sécurisée le client Docker auprès du démon, garantissant que seuls les clients autorisés ont accès au démon Docker.
Sécurisation de la communication entre les hôtes Docker
How to use Docker host inside application container. Image source: ClaudioKuenzler
Dans un essaim Docker ou un cluster Kubernetes, plusieurs hôtes Docker travaillent ensemble pour exécuter et gérer des conteneurs. Lorsque ces hôtes communiquent entre eux, la communication doit impérativement être sécurisée. [C’est là qu’interviennent] les certificats SSL/TLS pour chiffrer et authentifier la communication entre les hôtes Docker.
4 étapes pour sécuriser la communication entre les conteneurs Docker
Source de l’image: middlewareinventory.com
Lorsque plusieurs conteneurs Docker s’exécutent sur le même hôte, il peuvent avoir besoin de communiquer entre eux. Cependant, en l’absence de chiffrement et d’authentification des données, gare aux attaques de type « man-in-the-middle ». Les certificats SSL/TLS offrent alors une solution intéressante pour renforcer la sécurité des conteneurs Docker, en s’assurant que les communications sont chiffrées et authentifiées.
Nous avons vu les principaux cas d’usage pour sécuriser les communications Docker, voyons maintenant comment protéger les conteneurs Docker à l’aide de certificats SSL/TLS.
Étape 1 : Utilisez des certificats privés ou publics d’une autorité de certification de confiance
Une autorité de certification (AC) a, entre autres, pour rôle d’émettre des certificats SSL/TLS qui serviront à sécuriser la communication entre les hôtes Docker, les conteneurs et les clients. Les développeurs peuvent être parfois tentés d’utiliser des certificats auto-signés. Cela peut être dangereux pour votre infrastructure, dans la mesure où ces certificats auto-signés ne sont pas largement reconnus et qu’ils ne sont pas conformes aux standards publics. Nous préconisons par conséquent d’utiliser des certificats émis par une autorité de certification de confiance, comme GlobalSign, pour renforcer la sécurité de votre infrastructure.
Étape 2 : Générez des certificats et sécurisez vos secrets
Pour sécuriser votre infrastructure, vous avez non seulement besoin de certificats, mais ces certificats – et les clés privées – doivent aussi être stockés en toute sécurité. Le plug-in Hashicorp Vault — Atlas de GlobalSign permet aux entreprises de sécuriser les conteneurs Docker en obtenant leurs certificats SSL/TLS auprès d’Atlas et en stockant leurs secrets de manière sécurisée dans le coffre-fort ou « Vault ». En nous confiant la sécurité [de leurs certificats et clés], les entreprises peuvent ainsi se concentrer sur le développement de leurs applications.
Étape 3 : Configurez Docker pour utiliser des certificats TLS
Une fois vos certificats générés, Docker doit les configurer pour qu’ils puissent être utilisés. Le démon Docker doit être configuré pour écouter des connexions sécurisées SSL/TLS, ce qui permet ensuite de configurer le client Docker pour utiliser le certificat SSL/TLS lors de ses communications avec le démon. Votre conteneur devra ensuite être paramétré pour utiliser les certificats SSL/TLS, à l’aide de fichiers de configuration ou de variables d’environnement.
Étape 4 : Vérifiez que le certificat TLS fonctionne
Une fois la configuration terminée, vous devez impérativement vous assurer que le certificat SSL/TLS fonctionne. Vous pouvez, pour cela, tester la communication entre les hôtes Docker, les conteneurs et les clients afin de vous assurer qu’elle est bel et bien chiffrée et authentifiée.
Du fait de leur architecture, les conteneurs ont plus de risques de subir des attaques malveillantes que les machines virtuelles. Nous recommandons par conséquent aux entreprises et grands groupes de sécuriser leurs conteneurs et leurs environnements d’orchestration (comme Kubernetes) avec des certificats SSL/TLS. En tant qu’AC publique de confiance renommée, GlobalSign aide les entreprises à sécuriser leur infrastructure DevOps.