Avec la norme CI/CD, les applications modernes n'ont plus besoin d'être développées et livrées comme des monolithes. L'époque des "release days" et des mises à jour massives de produits avec de longs délais d'exécution et des efforts de développement cloisonnés est révolue. La popularité croissante et l'importance des applications conteneurisées ont conduit à la croissance de plateformes d'orchestration telles que Kubernetes, dont la sécurité est devenue essentielle maintenant qu'elle est critique pour de nombreuses applications modernes.
Mais comment prouver que ce que vous exécutez dans Kubernetes est bien ce que vous avez construit et prévu de déployer ? Les plateformes d'orchestration de conteneurs bénéficient grandement de la signature de code.
La signature de code est un élément de sécurité important dans une stratégie de développement "shift-left", où les mesures de sécurité sont intégrées dans le produit en tant que fonctionnalités avant sa livraison .
La signature de code renforce la sécurité et la confiance dans les pipelines de développement de software , en liant les artefacts software à l'identité et en confirmant leur intégrité par des signatures cryptographiques. La stratégie de certificat et d'identité n'est plus une prérogative de TLS et des identités des appareils ; l'étendre aux identités des développeurs et des constructeurs dans Kubernetes est une opportunité clé pour enrichir la confiance numérique dans votre organisation.
Le développement avec Kubernetes présente de nombreux avantages, mais aussi des pièges que la signature de code peut aider à résoudre. Lisez la suite pour une discussion sur les lacunes potentielles dans la sécurité de KubernetesComment la signature de code et l'PKI peuvent aider à combler ces lacunes, et les meilleures pratiques pour les flux de travail de sécurité des conteneurs signés.
Les lacunes de la sécurité de Kubernetes
L'infrastructure à clé publiquePKI est un élément indispensable du développement et de la fourniture d'applications. Kubernetes s'appuie certainement déjà s'appuie déjà sur la PKI pour ses nombreux composants. Le plan de contrôle, les kubelets, les certificats clients et bien d'autres utilisent tous des certificats X.509 et des demandes de signature de certificat (CSR) nativement.
Cependant, la portée de la mise en œuvre typique de l'PKI est souvent limitée à l'infrastructure, laissant les artefacts software fonctionnant dans des pods et des conteneurs exposés et potentiellement en danger si leur intégrité n'est pas vérifiée par d'autres moyens. A nomenclatureSoftware (SBOM) peut combler une partie de ce manque de visibilité en fournissant un inventaire complet des composants et des dépendances dans les images de conteneurs, tandis que la signature du code vérifie que ces images proviennent de sources fiables.
Alors que les équipes adoptent des pipelines CI/CD plus fluides et automatisés et utilisent des registres de conteneurs et des clusters Kubernetes, des images non signées ou compromises peuvent échapper aux outils d'analyse et être exécutées en production. Dans le meilleur des cas, il s'agit d'une erreur de bonne foi. Dans le pire des cas : des actifs compromis, des processus rompus et des retombées coûteuses. Les balises images mutables aggravent le risque, car quelqu'un peut réappuyer sur la même balise, en contournant les contrôles natifs. C'est pourquoi de nombreux guides d'architecture insistent sur la nécessité d'une signature cryptographique et d'une vérification des signatures dans le cluster.
Dans la pratique, bien sûr, les développeurs peuvent résister aux frictions que les procédures de signature introduisent dans le flux, ou utiliser par défaut des scripts ad hoc en dehors de la gouvernance.
Cela conduit à la signature de signature et à des pratiques de signature faibles, où les scripts de signature de code fonctionnent mal ou la signature n'est pas effectuée du tout. Les défis ne s'arrêtent pas là : une gestion intelligente des clés en phase avec les processus d'évolution exige non seulement une plus grande sécurité pour le stockage des clés privées (idéalement, dans des HSM ou des chambres fortes), mais aussi une gestion automatisée du cycle de vie des certificats pour assurer la cohérence entre les clusters.
L'application des politiques au moment de l'exécution est également une exigence pour des opérations Kubernetes plus sûres. Une fois qu'une image est signée, les contrôleurs d'admission ou les moteurs de politiques doivent vérifier que l'environnement Kubernetes n'exécute que des images dont les signatures sont valides et vérifiables. En outre, l'infrastructure de signature en question doit être suffisamment agile pour suivre l'évolution rapide du paysage de la cybersécurité et les progrès de la cryptographie. La mise en place d'une infrastructure agile qui n'impose pas de contraintes excessives aux ressources de l'organisation au fur et à mesure de son évolution est l'un des principaux défis de DevOps.
Comment combler le fossé de confiance en matière de sécurité Kubernetes ?
Compte tenu des défis liés à la mise en œuvre de la signature de code dans Kubernetes, il n'est pas surprenant que certains environnements ne l'utilisent toujours pas, malgré sa nécessité évidente.
Le flux de travail non sécurisé typique se déroule comme suit : Le développeur livre le code ; CI/CD construit une image de conteneur ; l'image est poussée vers un registre ; Kubernetes la met en production. Les problèmes ? Quelques-uns :
- Il n'existe aucune preuve cryptographique permettant de relier cette image à un processus de construction vérifié.
- Ainsi, toute personne ayant accès au registre pourrait remplacer ou altérer l'image, et Kubernetes la déploierait quand même, car il ne fait confiance qu'à l'étiquette.
- Le pipeline qui en résulte est efficace, mais est-il digne de confiance ? Il est définitivement invérifiable.
Il existe de nombreuses possibilités de sécuriser ce flux de travail, qui ne se limitent pas exclusivement à la signature de code.
Étape 1 : Introduire l'identité vérifiée dans le processus de construction
La signature de code rend les flux de travail des applications vérifiables et liés à une identité vérifiable. Avec un outil de gestion des certificats comme Keyfactor Commandun certificat de signature de code est délivré au système de construction par le biais du même cadre PKI qui sécurise TLS et les périphériques. Chaque version qui signe automatiquement son image de conteneur et les binaires associés devient une partie du flux de travail CI/CD sécurisé. Cette signature est liée à une identité gouvernée et vérifiable, au lieu d'une clé non gérée se trouvant sur un serveur de construction. Les clés peuvent être stockées dans des HSM intégrés ou des coffres-forts de clés en nuage, faire l'objet d'une rotation automatique et être révoquées en cas de compromission, conformément aux meilleures pratiques de l'PKI .
Étape 2 : Étendre la confiance à l'ensemble de la chaîne de distribution
Chaque image signée est poussée vers le registre de conteneurs avec sa signature numérique. Command conserve l'ancre de confiance et les métadonnées du certificat, de sorte que n'importe quel cluster Kubernetes peut vérifier l'image par rapport à la racine de confiance de l'organisation. Les paquets de confiance sont distribués automatiquement dans les environnements, quelle que soit la configuration (sur site, dans le nuage, hybride), de sorte que chaque cluster partage une politique de vérification cohérente, éliminant ainsi la dérive de configuration manuelle qui sape souvent la sécurité multi-clusters.
Étape 3 : Transformer Kubernetes en point d'exécution
Avec la signature de code en place, la fonctionnalité innée de Kubernetes peut renforcer la sécurité de l'ensemble du pipeline. Lorsqu'un développeur déploie une nouvelle image, un contrôleur d'admission ou un moteur de politique vérifie la signature avant de programmer le pod. En un sens, Kubernetes n'espère plus que l'image est légitime, mais la vérifie à l'aide de la preuve cryptographique émise dans le cadre de la gouvernance PKI de l'entreprise. Si la signature de l'image est manquante, expirée ou non fiable, le déploiement est automatiquement rejeté sans ralentir les libérations légitimes. Étant donné que cette mise en œuvre est basée sur des politiques et ne repose pas sur des scripts ad hoc, elle est intrinsèquement évolutive et cohérente entre les clusters.
Étape 4 : Introduire la gestion totale du cycle de vie avec Keyfactor Command
Utilisation d'outils PKI tels que Keyfactor Command pour les flux de travail relatifs à la sécurité des conteneurs présente les avantages d'une gestion totale du cycle de vie, de l'automatisation et de l'élimination de l'erreur humaine. Les clés de signature de code et les certificats suivent des cycles de vie définis et automatisables, depuis la création, la rotation et le renouvellement des certificats jusqu'à leur révocation et leur retrait. Les solutions automatisées de gestion du cycle de vie des certificats permettent aux entreprises de s'adapter facilement à l'évolution des normes cryptographiques.
Un flux de travail de sécurité Kubernetes mature vérifie les cases suivantes :
- Chaque artefact possède une signature vérifiable liée à une identité audible.
- Les équipes de sécurité visualisent l'activité de signature, l'état des certificats et l'application des politiques au sein des clusters sur un tableau de bord unique et unifié.
- Les journaux d'audit indiquent exactement quelle clé a signé quelle construction, à quel moment et sous quelle autorité, ce qui facilite la mise en conformité.
- Les identifiants de signature expirés ou perdus sont détectés et corrigés à temps, ce qui permet d'éviter toute panne ou vulnérabilité.
Meilleures pratiques de signature de code pour les flux de travail de sécurité Kubernetes.
La signature du code dans Kubernetes s'étend sur quatre couches intégrées : construction et signature, vérification et application, registre et stockage, distribution de la confiance et gestion du cycle de vie.
La couche de construction et de signature implique des pipelines CI/CD qui demandent automatiquement des identités de signature, à l'aide d'une émission basée sur des politiques liées à la PKI l'entreprise. Les contrôleurs d'admission de Kubernetes valident les signatures par rapport aux ancres de confiance gérées, de sorte que seules les charges de travail vérifiées sont autorisées à s'exécuter. Les images et les métadonnées signées sont stockées ensemble, ce qui signifie que la provenance voyage avec chaque artefact à travers les registres. Une automatisation réussie permet de synchroniser les paquets de confiance, de faire tourner les clés et de mettre à jour les normes cryptographiques sans interrompre les déploiements.
En gardant à l'esprit ces quatre couches de sécurité Kubernetes, voici quelques bonnes pratiques opérationnelles à mettre en œuvre :
- Déploiement d'images par digests immuables plutôt que par tags mutables pour prévenir les attaques par substitution
- Définition de politiques au niveau du cluster, afin que seules les charges de travail signées par des systèmes de construction autorisés soient autorisées.
- Stocker les clés de signature privée dans des HSM ou des coffres-forts intégrés, et automatiser leur rotation
- Conserver des pistes d'audit complètes des événements de signature et de vérification pour assurer la conformité
- Planification de la crypto-agilité, car les algorithmes de signature évoluent beaucoup plus rapidement que les cycles de vie des infrastructures.
Conclusion
La sécurité de Kubernetes englobe désormais non seulement la protection de l'infrastructure, mais aussi la sécurisation des actifs software avec la signature de code. L'intégration de la signature de code dans le flux de travail devient une pratique standard pour faire le lien entre l'agilité DevOps et l'assurance PKI , en veillant à ce que chaque charge de travail soit authentifiée et autorisée.
Lorsque vos clusters Kubernetes n'exécutent que des software vérifiés par cryptographie, la sécurité cesse d'être une hypothèse et devient une garantie opérationnelle.
Ce processus peut commencer à petite échelle : signer un seul pipeline CI/CD, appliquer les signatures dans un cluster, puis s'étendre à l'ensemble de l'organisation.
Keyfactor Command offre l'automatisation et la visibilité nécessaires pour la rendre évolutive, depuis l'émission et la rotation des certificats jusqu'à la gestion des faisceaux de confiance et l'intégration avec les outils CI/CD et Kubernetes.
L'avenir de la sécurité des conteneurs réside dans la confiance vérifiable. Prenez contact avec Keyfactor dès aujourd'hui pour nous aider à le construire. Vous avez des questions ? Notre équipe est là pour vous aider !
