Dix aspects pour renforcer la sécurité des conteneurs Linux

Dans un environnement conteneurisé, la construction de logiciels est une étape de tout le cycle de vie et le code de l'application doit être intégré au runtime. La gestion de ce processus de build est essentielle pour garantir la sécurité de votre pile logicielle. Adhérez au concept « construire une fois, déployer partout » pour garantir que les produits dans le processus de construction sont exactement les produits déployés en production. Ceci est également très important pour maintenir la stabilité continue des conteneurs. En d’autres termes, ne corrigez pas les conteneurs en cours d’exécution, mais reconstruisez-les et redéployez-les. Que vous travailliez dans un secteur hautement réglementé ou que vous souhaitiez simplement optimiser le travail de votre équipe, vous devez concevoir la gestion de vos images de conteneurs et créer des processus pour exploiter la couche conteneur afin d'obtenir une séparation des contrôles afin que :

L'équipe d'exploitation et de maintenance gère les images de base

L'équipe d'architecture gère le middleware, le runtime, la base de données et d'autres solutions

L'équipe de développement se concentre uniquement sur la couche application et le code

Enfin, signez vos conteneurs personnalisés pour vous assurer qu'ils ne sont pas altérés entre la construction et le déploiement.

Si des problèmes surviennent pendant le processus de création ou si des vulnérabilités sont découvertes après le déploiement d'une image, ajoutez une autre couche de sécurité avec un déploiement automatisé basé sur des politiques.

Jetons un coup d'œil aux trois couches d'images de conteneur utilisées pour créer des applications : noyau, middleware et application. Si un problème est découvert dans l'image principale, l'image sera reconstruite. Une fois la construction terminée, l'image sera transmise au serveur d'enregistrement de la plateforme de conteneurs. La plateforme peut détecter les modifications apportées à l'image. Pour les builds qui dépendent de cette image et ont des déclencheurs définis, la plateforme reconstruira automatiquement l'application et intégrera les bibliothèques corrigées.

Une fois la construction terminée, l'image sera transmise au serveur d'enregistrement interne de la plateforme de conteneurs. Les modifications apportées à l'image sur le serveur d'enregistrement interne sont détectées immédiatement et les images mises à jour sont automatiquement déployées via des déclencheurs définis dans l'application, garantissant que le code exécuté en production est toujours le même que l'image la plus récemment mise à jour. Toutes ces fonctionnalités fonctionnent ensemble pour intégrer des fonctionnalités de sécurité dans votre processus d'intégration continue et de déploiement continu (CI/CD).

Bien sûr, les candidatures sont rarement livrées dans un seul conteneur. Même les applications simples ont généralement un front-end, un back-end et une base de données. Le déploiement d'applications de microservices modernes dans des conteneurs signifie souvent le déploiement de plusieurs conteneurs, parfois sur le même hôte et parfois répartis sur plusieurs hôtes ou nœuds, comme le montre la figure.

Lorsque vous gérez des déploiements de conteneurs à grande échelle, vous devez prendre en compte :

Quels conteneurs doivent être déployés sur quel hôte ?

Quel hébergeur a la plus grande capacité ?

Quels conteneurs doivent accéder les uns aux autres ? Comment vont-ils se découvrir ?

Comment contrôler l'accès et la gestion des ressources partagées, telles que le réseau et le stockage ?

Comment surveiller l’état de santé des conteneurs ?

Comment étendre automatiquement les capacités des applications pour répondre à la demande ?

Comment permettre aux développeurs de répondre aux besoins de sécurité en libre-service ?

Compte tenu du large éventail de capacités que possèdent les développeurs et les opérateurs, un contrôle d'accès fort basé sur les rôles est un élément clé d'une plate-forme de conteneurs. Par exemple, le serveur de gestion d'orchestration est le point d'accès central et doit recevoir le plus haut niveau de contrôles de sécurité. Les API sont essentielles à la gestion automatisée des conteneurs à grande échelle, utilisées pour valider et configurer les données des conteneurs, des services et des contrôleurs de réplication ; effectuer la validation de projet sur les demandes entrantes et appeler des déclencheurs sur d'autres composants majeurs du système ;

Le déploiement d'applications de microservices modernes dans des conteneurs signifie souvent le déploiement de plusieurs conteneurs répartis sur plusieurs nœuds. En gardant à l’esprit la défense du réseau, vous avez besoin d’un moyen d’isoler les applications au sein d’un cluster.

Un service de cloud public typique, tel que Google Container Engine (GKE), Azure Container Services ou Amazon Web Services (AWS) Container Service, est un service à locataire unique. Ils permettent d'exécuter des conteneurs sur un cluster de VM que vous lancez. Pour garantir la sécurité des conteneurs multi-locataires, vous avez besoin d'une plate-forme de conteneurs qui vous permet de sélectionner un seul cluster et de segmenter le trafic pour isoler différents utilisateurs, équipes, applications et environnements au sein de ce cluster.

Avec les espaces de noms réseau, chaque ensemble de conteneurs (appelé « POD ») obtient sa propre plage d'adresses IP et de liaison de port, isolant ainsi le réseau POD sur le nœud.

Par défaut, les POD de différents espaces de noms (projets) ne peuvent pas envoyer ou recevoir de paquets de POD ou de services de différents projets, sauf avec les options décrites ci-dessous. Vous pouvez utiliser ces fonctionnalités pour isoler les environnements de développement, de test et de production dans un cluster. Toutefois, cette expansion des adresses IP et des ports rend la mise en réseau plus complexe. Investissez dans des outils pour gérer cette complexité. L'outil préféré consiste à utiliser une plate-forme de conteneurs de réseau défini par logiciel (SDN), qui fournit un réseau de cluster unifié pour assurer la communication entre les conteneurs de l'ensemble du cluster.

Les conteneurs sont très utiles pour les applications avec et sans état. La sécurisation du stockage est un élément clé pour garantir des services avec état. La plate-forme de conteneurs doit fournir une variété de plug-ins de stockage, notamment Network File System (NFS), AWS Elastic Block Stores (EBS, stockage de blocs élastiques), disque persistant GCE, GlusterFS, iSCSI, RADOS (CEPH), Cinder, etc.

Un volume persistant (PV) peut être monté sur n'importe quel hôte pris en charge par le fournisseur de ressources. Les fournisseurs auront des capacités différentes et le mode d'accès de chaque PV peut être défini sur un mode spécifique pris en charge par un volume spécifique. Par exemple, NFS peut prendre en charge plusieurs clients en lecture/écriture, mais un PV NFS particulier ne peut être exporté qu'en lecture seule sur le serveur. Chaque PV possède son propre ensemble de modes d'accès qui définissent des mesures de performances spécifiques au PV, telles que ReadWriteOnce, ReadOnlyMany et ReadWriteMany.

La sécurisation des applications comprend la gestion de l'authentification et de l'autorisation des applications et des API. La fonctionnalité Web SSO est un élément essentiel des applications modernes. Lorsque les développeurs créent leurs propres applications, la plate-forme de conteneurs peut leur fournir divers services de conteneurs.

L'API est un composant clé des applications de microservices. Les applications de microservices disposent de plusieurs services API indépendants, ce qui entraîne une prolifération de points de terminaison de service et nécessite donc davantage d'outils de gouvernance. Il est recommandé d'utiliser des outils de gestion d'API. Toutes les plates-formes API doivent fournir une variété d'options standard pour l'authentification et la sécurité des API, qui peuvent être utilisées seules ou en combinaison pour émettre des certificats et contrôler l'accès. Ces options incluent les clés API standard, les ID d'application, les paires de clés et OAuth 2.0.

En juillet 2016, Kubernetes 1.3 a introduit le cluster fédéré Kubernetes. Il s'agit d'une nouvelle fonctionnalité intéressante actuellement dans la version bêta de Kubernetes 1.6.

Dans les scénarios de cloud public ou de centre de données d'entreprise, la fédération est utile pour déployer et accéder aux services d'application sur plusieurs clusters. Le multicluster permet une haute disponibilité des applications, telles que plusieurs régions, plusieurs fournisseurs de cloud (tels qu'AWS, Google Cloud et Azure) pour parvenir à une gestion commune du déploiement ou de la migration.

Lors de la gestion de la fédération de cluster, vous devez vous assurer que l'outil d'orchestration fournit la sécurité requise sur les différentes instances de la plateforme de déploiement. Comme toujours, l'authentification et l'autorisation sont essentielles à la sécurité : pouvoir transmettre en toute sécurité des données aux applications, quel que soit l'endroit où elles s'exécutent, et gérer la multilocation des applications dans un cluster.

Kubernetes étend la fédération de cluster pour inclure la prise en charge du chiffrement fédéré, des espaces de noms fédérés et de la saisie d'objets.