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
La réparation est une responsabilité partagée entre Google et le client. Les responsabilités partagées sont différentes en fonction des plates-formes. Pour en savoir plus, consultez les rubriques suivantes sur chaque plate-forme :
- GKE
- Google Distributed Cloud (logiciel uniquement) sur VMware
- GKE sur AWS
- Google Distributed Cloud (logiciel uniquement) pour solution Bare Metal
- GKE sur Azure
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 des 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 dédié Google Cloud 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é recherche et corrige régulièrement des failles dans la KVM (machine virtuelle basée sur Kernel) (KVM). Google Cloud
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.
Correction des failles 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 maintenir les clusters corrigés et renforcer la sécurité contre les failles de tous niveaux de gravité, nous vous recommandons d'utiliser la mise à niveau automatique des nœuds sur GKE (activée par défaut). Pour les clusters enregistrés dans des canaux de publication, les versions de correctifs sont promues, car elles répondent aux exigences de qualification de chaque canal. Si vous avez besoin d'une version de correctif GKE avant qu'elle ne parvienne au canal de votre cluster, vous pouvez effectuer une mise à niveau manuelle vers la version de correctif si celle-ci se trouve sur la même version mineure qu'une disponible dans le version disponible de votre cluster.
Sur d'autres plates-formes sur lesquelles les clusters s'exécutent, Google recommande d'effectuer une mise à niveau au moins une fois par mois. Pour obtenir la liste des plates-formes, consultez la section précédente Responsabilité partagée des 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 une période appropriée en fonction des risques qu'elles représentent. GKE est inclus dans Google Cloud's agrément d'exploitation provisoire FedRAMP 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 d'évaluation des risques (RA) RA-5, "Analyse des failles", dans la feuille de calcul 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 correctifs qui corrigent la faille dans le délai correspondant. L'agrément d'exploitation provisoire Google Cloud FedRAMP n'inclut pas Google Distributed Cloud, GKE sur AWS, GKE sur Azure ni les clusters associés à GKE, mais nous nous efforçons de respecter les mêmes délais de correction sur ces produits. Une fois que GKE met à disposition des versions de correctifs pour corriger 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
- Google Kubernetes Engine (GKE)
- Google Distributed Cloud (logiciel uniquement) sur VMware
- GKE sur AWS
- GKE sur Azure
- Google Distributed Cloud (logiciel uniquement) sur solution Bare Metal
Ces bulletins suivent un schéma commun de numérotation des failles Google Cloud et sont accessibles à partir de la page principale Google Cloud des bulletins et des notes de version de GKE. Chaque page de bulletins de sécurité comporte un flux RSS sur lequel les utilisateurs peuvent s'abonner aux mises à jour.
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 seront 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 inter-canaux, des paramètres de correctifs accélérés et des notifications basées sur des é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 évaluées. Pour réduire les délais de correction, vous devez comprendre le fonctionnement de ces déploiements, puis adapter le comportement par défaut à vos besoins spécifiques.
L'évaluation 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 correctifs GKE sont d'abord introduites dans le canal rapide, puis dans les canaux standard et stable. Les versions sont également évaluées dans chaque canal avant de devenir la cible de mise à niveau par défaut pour le canal.
Qualifiez les correctifs en avance avec un cluster dédié dans le canal rapide
Pour qualifier un correctif de sécurité que vous souhaitez accélérer, exécutez un cluster dédié enregistré dans le canal rapide avec les mises à niveau automatiques de correctifs accélérées activées. Utilisez ce cluster pour vérifier la compatibilité des charges de travail et détecter tout problème dès qu'un correctif de sécurité est publié par Google. Ce cluster peut être utilisé comme qualification unique pour un correctif spécifique, mais son exécution continue offre des avantages de fiabilité supplémentaires à votre parc.
Réduisez les délais d'évaluation grâce aux mises à niveau automatiques de correctifs accélérées
Une fois que votre cluster enregistré dans le canal rapide est en place pour détecter les problèmes, vous pouvez choisir d'appliquer les correctifs plus rapidement dans vos clusters de production sur les canaux standard et stable. Activez les mises à niveau automatiques de correctifs accélérées pour vos clusters de production afin de commencer les mises à niveau vers la dernière version de correctif dans votre canal enregistré dès qu'elle est disponible. 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é.
Mises à niveau manuelles vers des versions de correctifs plus récentes dans les canaux standard et stable
Si vos charges de travail de production se trouvent sur des clusters enregistrés dans les canaux standard ou stable, vous n'avez pas besoin de quitter ces canaux ni d'attendre le déploiement automatique et progressif d'un correctif pour vous atteindre si vous avez besoin de donner la priorité à une mise à jour de sécurité spécifique.
Si votre cluster enregistré dans le canal rapide a qualifié un correctif, vous pouvez lancer manuellement une mise à niveau sur vos clusters de production dans les canaux standard ou stable vers cette version de correctif exacte.
Automatisez la gestion des correctifs avec les notifications Pub/Sub basées sur des événements
Il n'est pas nécessaire de surveiller la page Web des bulletins de sécurité pour obtenir des informations sur les correctifs. Pour recevoir des notifications programmatiques rapides des correctifs disponibles à l'aide de Pub/Sub afin de déclencher la qualification des correctifs et les actions de mise à niveau :
- Alertes basées sur des événements : configurez des notifications de cluster à l'aide de Pub/Sub.
- Filtrage de la sécurité : configurez les notifications de votre cluster pour filtrer spécifiquement les SecurityBulletinEvent et UpgradeEvent.
- Action programmatique : GKE envoie des messages programmatiques en temps réel à votre sujet Pub/Sub lorsqu'un bulletin de sécurité est publié ou qu'un correctif qui atténue un bulletin devient disponible pour votre cluster dans votre zone ou région. Ces notifications peuvent être intégrées à vos systèmes de gestion des informations et des événements de sécurité (SIEM), à vos opérations de chat ou à vos pipelines de test automatisés.