2.8. Sécuriser le processus de construction
Dans un environnement de conteneurs, le processus de construction du logiciel est l'étape du cycle de vie où le code de l'application est intégré aux bibliothèques d'exécution requises. La gestion de ce processus est essentielle pour sécuriser la pile logicielle.
2.8.1. Construire une fois, déployer partout
L'utilisation d'OpenShift Container Platform comme plateforme standard pour les constructions de conteneurs vous permet de garantir la sécurité de l'environnement de construction. L'adhésion à la philosophie "construire une fois, déployer partout" permet de s'assurer que le produit du processus de construction est exactement ce qui est déployé en production.
Il est également important de maintenir l'immuabilité de vos conteneurs. Vous ne devez pas patcher les conteneurs en cours d'exécution, mais les reconstruire et les redéployer.
Au fur et à mesure que votre logiciel passe par les étapes de construction, de test et de production, il est important que les outils qui composent votre chaîne d'approvisionnement en logiciels soient fiables. La figure suivante illustre le processus et les outils qui pourraient être incorporés dans une chaîne d'approvisionnement de logiciels de confiance pour les logiciels conteneurisés :
OpenShift Container Platform peut être intégrée à des référentiels de code fiables (tels que GitHub) et à des plateformes de développement (telles que Che) pour créer et gérer du code sécurisé. Les tests unitaires peuvent s'appuyer sur Cucumber et JUnit. Vous pouvez inspecter vos conteneurs pour détecter les vulnérabilités et les problèmes de conformité avec Anchore ou Twistlock, et utiliser des outils d'analyse d'images tels qu'AtomicScan ou Clair. Des outils tels que Sysdig peuvent assurer une surveillance continue de vos applications conteneurisées.
2.8.2. Gestion des constructions
Vous pouvez utiliser Source-to-Image (S2I) pour combiner le code source et les images de base. Builder images utilise S2I pour permettre à vos équipes de développement et d'exploitation de collaborer sur un environnement de construction reproductible. Avec les images S2I de Red Hat disponibles en tant qu'images de base universelles (UBI), vous pouvez désormais redistribuer librement vos logiciels avec des images de base construites à partir de véritables paquets RHEL RPM. Red Hat a supprimé les restrictions d'abonnement pour permettre cela.
Lorsque les développeurs livrent du code avec Git pour une application utilisant des images de construction, OpenShift Container Platform peut exécuter les fonctions suivantes :
- Déclencher, à l'aide de webhooks sur le dépôt de code ou d'un autre processus d'intégration continue automatisé, l'assemblage automatique d'une nouvelle image à partir des artefacts disponibles, de l'image du constructeur S2I et du code nouvellement livré.
- Déployer automatiquement l'image nouvellement créée pour la tester.
- Promouvoir l'image testée vers la production où elle peut être déployée automatiquement à l'aide d'un processus CI.
Vous pouvez utiliser le registre intégré OpenShift Container Registry pour gérer l'accès aux images finales. Les images S2I et les images natives sont automatiquement poussées vers votre OpenShift Container Registry.
En plus de Jenkins for CI, vous pouvez également intégrer votre propre environnement de construction et de CI à OpenShift Container Platform à l'aide d'API RESTful, ainsi qu'utiliser n'importe quel registre d'images compatible avec l'API.
2.8.3. Sécuriser les entrées lors de la construction
Dans certains cas, les opérations de compilation nécessitent des informations d'identification pour accéder à des ressources dépendantes, mais il n'est pas souhaitable que ces informations d'identification soient disponibles dans l'image finale de l'application produite par la compilation. Vous pouvez définir des secrets d'entrée à cette fin.
Par exemple, lorsque vous créez une application Node.js, vous pouvez configurer votre miroir privé pour les modules Node.js. Pour télécharger des modules à partir de ce miroir privé, vous devez fournir un fichier .npmrc personnalisé pour la construction qui contient une URL, un nom d'utilisateur et un mot de passe. Pour des raisons de sécurité, vous ne devez pas exposer vos informations d'identification dans l'image de l'application.
Dans cet exemple, vous pouvez ajouter un secret de saisie à un nouvel objet BuildConfig:
Créer le secret, s'il n'existe pas :
$ oc create secret generic secret-npmrc --from-file=.npmrc=~/.npmrc
Cela crée un nouveau secret nommé
secret-npmrc, qui contient le contenu encodé en base64 du fichier~/.npmrc.Ajoutez le secret à la section
sourcedans l'objet existantBuildConfig:source: git: uri: https://github.com/sclorg/nodejs-ex.git secrets: - destinationDir: . secret: name: secret-npmrcPour inclure le secret dans un nouvel objet
BuildConfig, exécutez la commande suivante :$ oc new-build \ openshift/nodejs-010-centos7~https://github.com/sclorg/nodejs-ex.git \ --build-secret secret-npmrc
2.8.4. Concevoir votre processus de construction
Vous pouvez concevoir votre gestion d'image de conteneur et votre processus de construction pour utiliser des couches de conteneur afin de pouvoir séparer le contrôle.
Par exemple, une équipe d'exploitation gère les images de base, tandis que les architectes gèrent les logiciels intermédiaires, les moteurs d'exécution, les bases de données et d'autres solutions. Les développeurs peuvent alors se concentrer sur les couches applicatives et sur l'écriture du code.
Comme de nouvelles vulnérabilités sont identifiées chaque jour, vous devez vérifier de manière proactive le contenu des conteneurs au fil du temps. Pour ce faire, vous devez intégrer des tests de sécurité automatisés dans votre processus de construction ou d'intégration. Par exemple :
- SAST / DAST - Outils de test de sécurité statique et dynamique.
- Des scanners permettant de vérifier en temps réel les vulnérabilités connues. Les outils de ce type cataloguent les paquets open source dans votre conteneur, vous informent des vulnérabilités connues et vous mettent à jour lorsque de nouvelles vulnérabilités sont découvertes dans des paquets précédemment analysés.
Votre processus d'intégration des données doit inclure des politiques qui signalent les constructions présentant des problèmes découverts par les analyses de sécurité, afin que votre équipe puisse prendre les mesures appropriées pour résoudre ces problèmes. Vous devez signer vos conteneurs personnalisés pour vous assurer que rien n'est altéré entre la construction et le déploiement.
En utilisant la méthodologie GitOps, vous pouvez utiliser les mêmes mécanismes CI/CD pour gérer non seulement les configurations de vos applications, mais aussi votre infrastructure OpenShift Container Platform.
2.8.5. Construire des applications Knative sans serveur
En s'appuyant sur Kubernetes et Kourier, vous pouvez construire, déployer et gérer des applications sans serveur en utilisant OpenShift Serverless dans OpenShift Container Platform.
Comme pour les autres builds, vous pouvez utiliser les images S2I pour construire vos conteneurs, puis les servir à l'aide des services Knative. Visualisez les builds d'applications Knative via la vue Topology de la console web OpenShift Container Platform.
