Ce document décrit la manière dont Google gère les failles et correctifs de sécurité pour Google Kubernetes Engine (GKE). Ces informations peuvent être utiles aux spécialistes de la sécurité qui aident à résoudre les problèmes de sécurité ou les failles nécessitant une assistance stratégique, tels que les incidents et les problèmes transmis par l'assistance.
Responsabilité partagée des correctifs
Google et le client se partagent la responsabilité de l'application de correctifs, comme décrit dans la section Responsabilité partagée de GKE.
Détection des failles
Google a réalisé d'importants investissements dans la conception et le renforcement en matière de sécurité de façon proactive, mais même les systèmes logiciels les mieux conçus peuvent causer des failles. Afin de détecter ces failles et de les corriger avant qu'elles puissent être exploitées, Google a effectué des investissements considérables sur plusieurs aspects.
À des fins de correction, GKE est la couche du système d'exploitation (OS) sur laquelle les conteneurs sont exécutés. Les systèmes d'exploitation, Container-Optimized OS ou Ubuntu, sont renforcés et contiennent la quantité minimale de logiciels requis pour exécuter les conteneurs. Les fonctionnalités GKE s'exécutent en tant que conteneurs sur les images de base. GKE s'efforce constamment de réduire le nombre de dépendances des composants système, ce qui permet de réduire la surface d'attaque et d'améliorer l'efficacité de la gestion des failles. Par exemple, les composants système GKE peuvent utiliser des images de base minimales lorsque cela est possible.
Google identifie et corrige les failles et les correctifs manquants comme suit :
Container-Optimized OS : Google analyse les images pour identifier les failles potentielles et les correctifs manquants. L'équipe Container-Optimized OS examine et résout les problèmes.
Ubuntu : Canonical fournit à Google des builds d'OS sur lesquels tous les correctifs de sécurité disponibles sont appliqués.
Google analyse les conteneurs à l'aide de Container Registry Artifact Analysis pour détecter les failles et les correctifs manquants dans les conteneurs gérés par Kubernetes et Google. Si des correctifs sont disponibles, l'outil d'analyse lance automatiquement le processus de correction et de déploiement.
En plus de l'analyse automatisée, Google détecte et corrige les failles inconnues aux scanners de différentes manières.
Google effectue ses propres audits, tests d'intrusion et découverte de failles sur toutes les plates-formes. Pour obtenir la liste des plates-formes, consultez la section précédente Responsabilité partagée concernant l'application de correctifs.
Les équipes spécialisées au sein de Google et les fournisseurs de sécurité tiers de confiance effectuent leurs propres recherches sur les attaques. Google s'est également associé à la Cloud Native Computing Foundation (CNCF) pour fournir une grande partie de l'expertise en organisation et en conseil technique pour l'audit de sécurité Kubernetes.
Google s'implique activement dans la communauté de recherche en sécurité par la biais de plusieurs programmes de récompenses pour la détection de failles. Un programme de récompenses pour la détection de failles Google Cloud dédié offre des primes significatives, y compris 133 337 $ pour la plus grande faille dans le cloud détectée chaque année. Pour GKE, il existe un programme qui récompense les chercheurs en sécurité s'ils peuvent briser les contrôles de sécurité. Le programme couvre toutes les dépendances logicielles de GKE.
Google collabore avec des partenaires logiciels Open Source et d'autres secteurs, qui partagent des failles, des recherches en sécurité et des correctifs avant que la version publique de ces failles ne soit publiée. L'objectif de cette collaboration est de corriger des éléments importants de l'infrastructure Internet avant que la faille ne soit annoncée publiquement. Dans certains cas, Google contribue aux failles détectées dans cette communauté. Par exemple, le projet Zero de Google a permis de détecter et de rendre public les failles Spectre et Meltdown. L'équipe de sécurité Google Cloud recherche et corrige régulièrement des failles dans la KVM (machine virtuelle basée sur Kernel) (KVM).
La collaboration sur la sécurité de Google a de nombreux niveaux. Elle arrive parfois par le biais de programmes où les organisations s'inscrivent pour recevoir des notifications préliminaires concernant des failles logicielles pour des produits tels que Kubernetes et . Envoy. La collaboration se fait également de manière informelle en raison de notre engagement auprès de nombreux projets Open Source, tels que le noyau Linux, les environnements d'exécution des conteneurs, la technologie de virtualisation, et bien plus encore.
Pour Kubernetes, Google est un membre fondateur actif du comité de sécurité des produits et a rédigé une grande partie du processus de publication en matière de sécurité. Google est membre de la liste des distributeurs Kubernetes qui reçoivent une notification préalable des failles, et s'est engagé dans le tri, l'application de correctifs, le développement de mesures d'atténuation et la communication de pratiquement toutes les failles de sécurité critiques de Kubernetes. Google a également découvert plusieurs failles Kubernetes, telles que CVE-2019-11254, CVE-2019-11255 et CVE-2021-25741.
Bien que les failles moins critiques soient découvertes et corrigées en dehors de ces processus, les failles de sécurité les plus critiques sont signalées en mode privé via l'un des canaux répertoriés précédemment. La création précoce de rapports laisse du temps à Google avant que la faille ne devienne publique afin d'étudier son impact sur GKE, de développer des correctifs ou des mesures d'atténuation, et de préparer des conseils et des communications pour les clients. Lorsque cela est possible, Google corrige tous les clusters avant l'annonce publique de la faille.
Classement des failles
GKE réalise des investissements importants dans le renforcement de la sécurité sur l'intégralité de la pile, y compris les couches du système d'exploitation, du conteneur, de Kubernetes et du réseau, en plus de définir de manière appropriée les valeurs par défaut, les configurations à sécurité renforcée et les composants gérés. Ces efforts combinés permettent de réduire l'impact et la probabilité des failles.
L'équipe de sécurité GKE classe les failles en fonction du système de classement des failles Kubernetes. Les classifications tiennent compte de plusieurs facteurs, y compris de la configuration et du renforcement de la sécurité dans GKE. En raison de ces facteurs et des investissements que GKE réalise concernant la sécurité, les classements des failles de GKE peuvent différer des autres sources de classement.
Le tableau suivant décrit les catégories de gravité des failles :
| Gravité | Description |
|---|---|
| Critique | Faille facilement exploitable dans tous les clusters par un pirate informatique non authentifié à distance, qui entraîne un piratage de l'intégralité du système. |
| Élevée | Faille facile à exploiter pour de nombreux clusters qui entraîne une perte de confidentialité, d'intégrité ou de disponibilité. |
| Moyenne | Une faille utilisable pour certains clusters où la perte de confidentialité, d'intégrité ou de disponibilité est limitée par des configurations courantes, la difficulté de l'exploitation elle-même, l'accès requis ou l'interaction utilisateur. |
| Faible | Toutes les autres failles. L'exploitation est peu probable, ou les conséquences de l'exploitation sont limitées. |
Consultez les bulletins de sécurité pour obtenir des exemples de failles, de correctifs et d'atténuations, ainsi que leurs notes.
Comment les failles sont-elles corrigées pour les clusters GKE ?
La réparation d'une faille implique la mise à niveau vers un nouveau numéro de version GKE. Les versions de GKE incluent des composants avec versions gérées pour le système d'exploitation, les composants Kubernetes et d'autres conteneurs qui constituent la plate-forme GKE. La réparation de certaines failles ne nécessite qu'une mise à niveau d'un plan de contrôle, effectuée automatiquement par Google sur GKE, tandis que d'autres nécessitent à la fois des mises à niveau du plan de contrôle et des nœuds.
Pour renforcer la sécurité des clusters contre les failles de tous niveaux de gravité, nous vous recommandons de suivre les bonnes pratiques pour la mise à niveau des clusters GKE. Vous pourrez ainsi vous assurer que votre cluster reçoit les correctifs de sécurité en temps voulu.
Google recommande de mettre à niveau les clusters Kubernetes au moins une fois par mois. Pour obtenir la liste des plates-formes, consultez la section précédente Responsabilité partagée concernant l'application de correctifs.
Certains analyseurs de sécurité ou certaines vérifications de version manuelles peuvent supposer à tort qu'un composant tel que runc ou containerd ne dispose pas d'un correctif de sécurité en amont spécifique. GKE corrige régulièrement les composants et n'effectue des mises à niveau de version de package que si nécessaire, ce qui signifie que les composants GKE sont fonctionnellement similaires à leurs équivalents en amont, même si le numéro de version du composant GKE ne correspond pas au numéro de version en amont. Pour en savoir plus sur une faille CVE spécifique, consultez les bulletins de sécurité GKE.
Calendrier des correctifs
L'objectif de Google est de réduire les failles détectées dans un délai approprié en fonction des risques qu'elles représentent. GKE est inclus dans l'agrément d'exploitation provisoire FedRAMP deGoogle Cloud, ce qui nécessite la correction des failles connues dans des délais spécifiques en fonction de leur niveau de gravité, comme spécifié dans le contrôle RA-5(d) de l'enregistrement RA-5 "Analyse des failles" de la feuille de calcul Base de référence des contrôles de sécurité FedRAMP.
Pour chaque faille connue, l'objectif de GKE est de publier des versions de correctif qui la corrigent dans le délai correspondant. Une fois que GKE met à disposition des versions de correctif pour remédier à une faille connue, mettez à niveau vos clusters vers ces versions afin de respecter les délais de correction de votre organisation.
Communication des failles et des correctifs
Les meilleures sources d'informations actuelles sur les failles et les correctifs de sécurité pour GKE sont les bulletins de sécurité et les notes de version.
À partir du 1er juin 2026, GKE ne publiera plus de bulletins de sécurité pour Google Distributed Cloud (logiciel uniquement), GKE sur AWS ni GKE sur Azure. Pour consulter les bulletins de sécurité et les correctifs de failles les plus récents pour ces produits, consultez les documents suivants :
Les failles de sécurité sont parfois préservées sous embargo pendant une durée limitée. Les embargoes empêchent la publication précoce de failles susceptibles de générer des tentatives d'exploitation dispersées à grande échelle avant de prendre les mesures nécessaires. Dans les situations d'embargo, les notes de version font référence à des "mises à jour de sécurité" jusqu'à la levée du secret. Une fois l'embargo levé, Google met à jour les notes de version afin d'inclure les failles spécifiques.
L'équipe de sécurité GKE publie des bulletins de sécurité pour les failles de gravité élevée et critique. Lorsque la réaction du client est requise pour remédier à ces failles critiques, Google contacte les clients par e-mail. Google peut également contacter les clients par le biais de contrats d'assistance via des canaux d'assistance.
Quel est le moyen le plus rapide d'installer un correctif de sécurité ?
Tous les clusters resteront automatiquement corrigés grâce aux mises à niveau automatiques de GKE. Cette section explique comment appliquer des correctifs plus rapidement que les mises à niveau automatiques pour des correctifs de sécurité spécifiques ou de manière continue. En combinant des environnements de test, des mises à niveau manuelles multicanaux, des paramètres de correctifs accélérés et des notifications basées sur les événements, vous pouvez réduire les délais de correction.
GKE gère les déploiements de versions sur les canaux de publication pour s'assurer que les nouvelles versions sont qualifiées et testées. Pour réduire vos délais de déploiement des correctifs, vous devez comprendre comment ces déploiements fonctionnent, puis adapter le comportement par défaut à vos besoins spécifiques.
Le trempage d'une version corrigée consiste à l'exécuter sur des clusters au fil du temps pour observer sa stabilité. Ce processus permet de détecter les bugs qui n'apparaissent qu'après une utilisation prolongée dans différents environnements. Pour garantir un temps de stabilisation suffisant, les versions de correctif GKE sont d'abord introduites dans le canal rapide, puis dans les canaux standard et stable. Les versions sont également testées dans chaque canal avant de devenir la cible de mise à niveau pour le canal.
Qualifiez les correctifs de manière anticipée et gérez le déploiement avec le séquençage du déploiement
Pour qualifier un correctif de sécurité que vous souhaitez accélérer, utilisez le séquençage du déploiement pour le déployer dans tous les environnements. Testez le correctif dans d'autres clusters GKE avant de mettre à niveau l'environnement de production. Cette approche vous permet de vérifier la compatibilité des charges de travail et de détecter les problèmes dès qu'un correctif de sécurité est publié par Google. Vous pouvez ensuite appliquer la version corrigée au reste de votre parc et contrôler le temps de stabilisation restant.
Réduire les délais de test grâce aux mises à niveau automatiques accélérées des correctifs
Vous pouvez également choisir de consommer les correctifs plus rapidement en activant les mises à niveau automatiques accélérées des correctifs pour vos clusters. Cette fonctionnalité indique à GKE de contourner le temps de stabilisation dans le canal pour les mises à jour de correctifs, en particulier les correctifs de sécurité. Si vous utilisez cette approche, Google vous recommande d'exécuter un cluster de test sur le canal rapide (également avec les mises à jour automatiques accélérées des correctifs) pour qualifier les correctifs.
Mises à niveau manuelles vers des versions de correctif plus récentes dans les canaux standard et stable
Si vos charges de travail de production se trouvent sur des clusters inscrits aux canaux "Standard" ou "Stable", vous n'avez pas besoin de quitter ces canaux ni d'attendre le déploiement progressif et automatique d'un correctif pour l'obtenir si vous devez donner la priorité à une mise à jour de sécurité spécifique.
Si vous avez qualifié la version corrigée, vous pouvez lancer manuellement les mises à niveau sur vos clusters en version "Régulière" ou "Stable" vers cette version corrigée exacte pour contrôler le temps de stabilisation restant.
Automatiser la gestion des correctifs avec les notifications de cluster
Il n'est pas nécessaire de consulter la page Web des bulletins de sécurité pour obtenir des informations sur les correctifs. Pour recevoir rapidement des notifications par programmation concernant les correctifs disponibles et déclencher des actions de qualification et de mise à niveau des correctifs, vous pouvez utiliser les notifications de cluster.
Pour recevoir des notifications concernant les bulletins de sécurité ou les mises à niveau planifiées, configurez vos notifications afin de filtrer spécifiquement les types d'événements suivants :
Les notifications de cluster vous permettent de recevoir des messages en temps réel lorsque ces événements se produisent. Vous pouvez intégrer ces notifications à vos systèmes de gestion des informations et des événements de sécurité (SIEM), à vos opérations de chat ou déclencher des pipelines de tests automatisés.