Pour afficher les bulletins de sécurité les plus récents, consultez la page Bulletins de sécurité.
Bulletins de sécurité GKE
14 novembre 2019
Date de publication : 14-11-2019Dernière mise à jour : 14-11-2019
Description | Gravité | Remarques |
---|---|---|
La communauté Kubernetes a divulgué une faille de sécurité dans les side-cars kubernetes-csi
Que dois-je faire ?
Quelles failles ce correctif permet-il de résoudre ? |
Moyen |
12 novembre 2019
Date de publication : 12-11-2019Dernière mise à jour : 12-11-2019
Description | Gravité | Remarques |
---|---|---|
Intel a divulgué des failles CVE qui permettent des interactions entre l'exécution spéculative et l'état microarchitectural afin d'exposer les données. Pour en savoir plus, consultez le communiqué d'Intel. L'infrastructure hôte qui exécute Kubernetes Engine isole les charges de travail des clients. À moins que vous n'exécutiez du code non approuvé dans vos propres clusters GKE mutualisés et que vous n'utilisiez des nœuds N2, M2 ou C2, aucune autre action n'est requise. Pour les instances GKE exécutées sur des nœuds N1, aucune nouvelle action n'est requise. Si vous exécutez Google Distributed Cloud, l'exposition dépend du matériel utilisé. Veuillez comparer votre infrastructure à celle décrite dans le communiqué d'Intel. Que dois-je faire ?Vous n'êtes affecté que si vous utilisez des pools de nœuds N2, M2 ou C2 et si ces nœuds utilisent du code non approuvé dans vos propres clusters GKE mutualisés.
Le redémarrage des nœuds permet d'appliquer le correctif. Le moyen le plus simple de redémarrer l'ensemble des nœuds de votre pool consiste à effectuer une opération de mise à niveau. Celle-ci force le redémarrage de tous les nœuds du pool concerné. Quelles failles ce correctif permet-il de résoudre ?Ce correctif réduit les risques liés aux failles suivantes : CVE-2019-11135 : cette faille CVE est également appelée TSX Async Abort (TAA). L'attaque TAA fournit un autre moyen d'exfiltrer des données qui utilise les mêmes structures de données microarchitecturales que celles exploitées par les failles Microarchitectural Data Sampling (MDS). CVE-2018-12207 : faille de déni de service (DoS) affectant les hôtes des machines virtuelles de sorte qu'un système invité malveillant puisse provoquer le plantage d'un hôte non protégé. Cette faille CVE est également appelée "Machine Check Error on Page Size Change" (Erreur de vérification de machine lors de la modification de la taille de page). Elle n'affecte pas GKE. |
Moyen |
22 octobre 2019
Date de publication : 22-10-2019Dernière mise à jour : 22-10-2019
Description | Gravité | Remarques |
---|---|---|
La faille CVE-2019-16276 a été récemment découverte dans le langage de programmation Go. Elle peut affecter les configurations Kubernetes utilisant un proxy d'authentification. Pour en savoir plus, consultez le communiqué de Kubernetes. Kubernetes Engine n'est pas affecté par cette faille, car il ne permet pas la configuration d'un proxy d'authentification. |
Aucun |
16 octobre 2019
Date de publication : 16-10-2019Dernière mise à jour : 24-10-2019
Description | Gravité | Remarques |
---|---|---|
Mise à jour du 24/10/2019 : les versions corrigées sont désormais disponibles dans toutes les zones. La faille CVE-2019-11253 a été récemment découverte dans Kubernetes. Elle permet à tout utilisateur autorisé à effectuer des requêtes POST de réaliser une attaque par déni de service à distance sur un serveur d'API Kubernetes. Le comité de sécurité des produits (PSC, Product Security Committee) Kubernetes a publié des informations complémentaires sur cette faille. Pour les consulter, cliquez ici. Les clusters GKE qui utilisent des réseaux autorisés maîtres et des clusters privés sans accès à un point de terminaison public réduisent les risques liés à cette faille. Que dois-je faire ?Nous vous recommandons de mettre à niveau votre cluster vers une version du correctif permettant de remédier à cette faille dès sa mise à disposition. Elle devrait être proposée dans toutes les zones avec la version de GKE planifiée pour la semaine du 14 octobre. Les versions du correctif permettant de limiter les risques liés à cette faille sont indiquées ci-dessous.
Quelles failles ce correctif permet-il de résoudre ?Ce correctif réduit les risques liés aux failles suivantes : CVE-2019-11253 est une faille par déni de service (DoS). |
Élevé |
16 septembre 2019
Date de publication : 16-09-2019Dernière mise à jour : 16-10-2019
Description | Gravité | Remarques |
---|---|---|
Ce bulletin a été mis à jour depuis sa publication initiale. Le langage de programmation Go a récemment découvert de nouvelles failles de sécurité, CVE-2019-9512 et CVE-2019-9514. Il s'agit de failles par déni de service (DoS). Dans GKE, elles permettent à un utilisateur de créer des requêtes malveillantes qui surutilisent le processeur du serveur d'API Kubernetes, ce qui risque de réduire la disponibilité du plan de contrôle du cluster. Pour en savoir plus, consultez le communiqué sur le langage de programmation Go. Que dois-je faire ?Nous vous recommandons de mettre à niveau votre cluster vers la dernière version du correctif, qui permet de limiter les risques liés à cette faille, dès sa mise à disposition. Elle devrait être proposée dans toutes les zones avec la prochaine version de GKE, selon le calendrier des lancements. Les versions du correctif permettant de limiter les risques liés à cette faille sont indiquées ci-dessous.
Quelles failles ce correctif permet-il de résoudre ?Ce correctif réduit les risques liés aux failles suivantes : CVE-2019-9512 et CVE-2019-9514 sont des failles par déni de service (DoS). |
Élevé |
5 septembre 2019
Date de publication : 05-09-2019Dernière mise à jour : 05-09-2019
Le bulletin concernant le correctif de la faille documentée dans le bulletin du 31 mai 2019 a été mis à jour.
22 août 2019
Date de publication : 22-08-2019Dernière mise à jour : 22-08-2019
Le bulletin du 5 août 2019 a été mis à jour. Le correctif de la faille documentée dans le bulletin antérieur est disponible.
8 août 2019
Date de publication : 08-08-2019Dernière mise à jour : 08-08-2019
Le bulletin du 5 août 2019 a été mis à jour. Le correctif de la faille documentée dans ce bulletin devrait être disponible dans la prochaine version de GKE.
5 août 2019
Date de publication : 05-08-2019Dernière mise à jour : 09-08-2019
Description | Gravité | Remarques |
---|---|---|
Ce bulletin a été mis à jour depuis sa publication initiale. La communauté Kubernetes a récemment découvert une faille de sécurité, CVE-2019-11247, qui permet d'intervenir sur les instances de ressources personnalisées à l'échelle d'un cluster comme s'il s'agissait d'objets présents dans tous les espaces de noms. Cela signifie que les comptes utilisateur et de service ne disposant que d'autorisations RBAC au niveau de l'espace de noms peuvent interagir avec des ressources personnalisées à l'échelle du cluster. Pour exploiter cette faille, le pirate informatique doit disposer de privilèges permettant d'accéder aux ressources de n'importe quel espace de noms. Que dois-je faire ?Nous vous recommandons de mettre à niveau votre cluster vers la dernière version du correctif, qui permet de limiter les risques liés à cette faille, dès sa mise à disposition. Elle devrait être proposée dans toutes les zones avec la prochaine version de GKE. Les versions du correctif permettant de limiter les risques liés à cette faille sont indiquées ci-dessous.
Quelle faille ce correctif permet-il de résoudre ?Le correctif limite les risques liés à la faille suivante : CVE-2019-11247. |
Moyen |
3 juillet 2019
Date de publication : 03-07-2019Dernière mise à jour : 03-07-2019
Description | Gravité | Remarques |
---|---|---|
Une version corrigée de Remarque : Le correctif n'est pas disponible dans |
Élevé |
3 juillet 2019
Date de publication : 25-06-2019Dernière mise à jour : 03-07-2019
Description | Gravité | Remarques |
---|---|---|
Mise à jour du 3 juillet 2019Lors de notre dernière mise à jour, les correctifs des versions 1.11.9 et 1.11.10 n'étaient pas encore disponibles. Nous avons publié 1.11.10-gke.5 en tant que cible de mise à niveau des deux versions 1.11. À l'heure actuelle, les instances maîtres de GKE ont été corrigées, de même que l'infrastructure de Google qui exécute Kubernetes Engine. Celle-ci est donc protégée contre cette faille. Les instances maîtres 1.11 seront bientôt obsolètes. La mise à niveau vers la version 1.12 est planifiée pour s'exécuter automatiquement la semaine du 8 juillet 2019. Vous pouvez exécuter l'une des actions suggérées ci-dessous pour mettre à niveau les nœuds vers une version corrigée.
Bulletin initial du 24 juin 2019 : Mise à jour du 24 juin 2019Depuis le 22/06/2019 21:40 UTC, nous avons mis à disposition les versions corrigées de Kubernetes qui sont indiquées ci-dessous. Les instances maîtres exécutant des versions de Kubernetes comprises entre 1.11.0 et 1.13.6 seront automatiquement mises à niveau vers une version corrigée. Si vous n'exécutez pas une version compatible avec ce correctif, procédez à la mise à niveau vers une version compatible de l'instance maître (voir la liste ci-dessous) avant de mettre à niveau les nœuds. En raison de la gravité de ces failles, que la mise à niveau automatique des nœuds soit activée ou non, nous vous recommandons de mettre à niveau manuellement dès que possible les nœuds et les instances maîtres vers l'une de ces versions. Versions corrigées :
Bulletin initial du 18 juin 2019 : Récemment, Netflix a révélé trois failles TCP dans les noyaux Linux : Ces failles CVE sont collectivement désignées par l'appellation NFLX-2019-001. Les noyaux Linux non corrigés peuvent être vulnérables face aux attaques par déni de service déclenchées à distance. Les nœuds Google Kubernetes Engine qui envoient ou reçoivent du trafic réseau non approuvé sont affectés. Par conséquent, nous vous recommandons de suivre les procédures de limitation des risques qui sont présentées ci-dessous pour protéger vos charges de travail. Maîtres Kubernetes
Nœuds KubernetesLes nœuds qui limitent le trafic vers les réseaux approuvés ne sont pas affectés. Ils correspondent à des clusters présentant les caractéristiques suivantes :
Google prépare un correctif permanent pour ces failles. Il sera proposé sous la forme d'une nouvelle version de nœud. Nous mettrons à jour ce bulletin et enverrons un e-mail à tous les clients GKE pour les avertir de la disponibilité de ce correctif. En attendant que le correctif permanent soit disponible, nous avons créé un DaemonSet Kubernetes qui met en œuvre les mesures d'atténuation en modifiant la configuration Que dois-je faire ?
Appliquez le DaemonSet Kubernetes à tous les nœuds de votre cluster en exécutant la commande ci-dessous. Vous ajoutez ainsi une règle kubectl apply -f \ https://raw.githubusercontent.com/GoogleCloudPlatform\ /k8s-node-tools/master/drop-small-mss/drop-small-mss.yaml Dès qu'une version de nœud corrigée sera disponible et que vous aurez mis à niveau tous les nœuds susceptibles d'être affectés, vous pourrez supprimer le DaemonSet à l'aide de la commande ci-dessous. Exécutez la commande une fois pour chaque cluster et chaque projet Google Cloud. kubectl delete -f \ https://raw.githubusercontent.com/GoogleCloudPlatform\ /k8s-node-tools/master/drop-small-mss/drop-small-mss.yaml |
Élevé Moyen Moyen |
CVE-2019-11477 CVE-2019-11478 CVE-2019-11479 |
25 juin 2019
Description | Gravité | Remarques |
---|---|---|
Mise à jour du 03/07/2019 : ce correctif est disponible dans Remarque : Le correctif n'est pas disponible dans la version 1.11.10.
La communauté Kubernetes a récemment découvert la faille CVE-2019-11246, qui permet à un pirate informatique ayant accès à une opération Toutes les versions de Que dois-je faire ?
Une version corrigée de Pour vérifier la disponibilité de ce correctif, consultez les notes de version de Quelle faille ce correctif permet-il de résoudre ?
La faille CVE-2019-11246 permet à un pirate informatique ayant accès à une opération |
Élevé |
18 juin 2019
Description | Gravité | Remarques |
---|---|---|
Docker a récemment découvert la faille CVE-2018-15664, qui permet à un pirate informatique pouvant exécuter du code dans un conteneur de détourner une opération Tous les nœuds Google Kubernetes Engine (GKE) exécutant Docker sont affectés par cette faille. Par conséquent, nous vous recommandons de procéder à la mise à niveau vers la dernière version du correctif dès qu'elle sera disponible. Une prochaine version du correctif permettra de limiter les risques liés à cette faille.
Toutes les instances maîtres Google Kubernetes Engine (GKE) antérieures à la version 1.12.7 exécutent Docker et sont affectées par cette faille.
Sur GKE, les utilisateurs n'ont pas accès à Que dois-je faire ?
Seuls les nœuds exécutant Docker sont affectés, et uniquement lorsqu'une commande Pour mettre à niveau vos nœuds, vous devez d'abord mettre à niveau votre instance maître vers la version corrigée. Lorsque le correctif sera disponible, vous pourrez lancer une mise à niveau de l'instance maître ou attendre que Google procède automatiquement à cette opération. Le correctif sera disponible dans Docker 18.09.7, qui figurera dans un prochain correctif de GKE. Ce correctif ne sera proposé que pour les versions 1.13 et ultérieures de GKE. Nous mettrons automatiquement à niveau les instances maîtres du cluster vers la version corrigée, selon le rythme de mise à niveau habituel. Vous pourrez également lancer vous-même une mise à niveau des instances maîtres lorsque la version corrigée sera disponible. Nous mettrons à jour ce bulletin en y ajoutant les versions contenant un correctif une fois qu'elles seront disponibles. Pour vérifier la disponibilité de ces correctifs, consultez les notes de version. Quelle faille ce correctif permet-il de résoudre ?Ce correctif réduit les risques liés à la faille suivante :
La faille CVE-2018-15664 permet à un pirate informatique pouvant exécuter du code dans un conteneur de détourner une opération |
Élevé |
31 mai 2019
Description | Gravité | Remarques |
---|---|---|
Ce bulletin a été mis à jour depuis sa publication initiale. Mise à jour du 2 août 2019Au moment de la publication du bulletin initial, seules les versions 1.13.6-gke.0 à 1.13.6-gke.5 étaient affectées. En raison d'une régression, toutes les versions 1.13.6.x sont désormais concernées. Si vous exécutez la version 1.13.6, procédez le plus rapidement possible à la mise à niveau vers la version 1.13.7.
Le projet Kubernetes a divulgué la faille CVE-2019-11245 dans les kubelets v1.13.6 et v1.14.2. Celle-ci peut entraîner l'exécution des conteneurs en tant qu'UID 0 (qui correspond généralement à l'utilisateur
Si une valeur Comment savoir si j'exécute une version affectée ?Exécutez la commande suivante pour répertorier tous les nœuds et la version de kubelet associée : kubectl get nodes -o=jsonpath='{range .items[*]}'\ '{.status.nodeInfo.machineID}'\ '{"\t"}{.status.nodeInfo.kubeletVersion}{"\n"}{end}' Si les versions de kubelet suivantes sont renvoyées dans le résultat, vos nœuds sont affectés :
Comment savoir si ma configuration spécifique est affectée ?Si vos conteneurs s'exécutent en tant qu'utilisateur non racine, et si vous utilisez une version de nœud comprise entre 1.13.6-gke.0 et 1.13.6-gke.6, votre configuration est affectée sauf dans les cas suivants :
Que dois-je faire ?Définissez le contexte de sécurité RunAsUser sur tous les pods du cluster qui ne doivent pas s'exécuter en tant qu'UID 0. Vous pouvez appliquer cette configuration à l'aide d'une règle PodSecurityPolicy. |
Moyen | CVE-2019-11245 |
14 mai 2019
Description | Gravité | Remarques |
---|---|---|
Mise à jour du 11/06/2019 : le correctif est disponible dans les versions 1.11.10-gke.4, 1.12.8-gke.6 et 1.13.6-gke.5 publiées la semaine du 28/05/2019, ainsi que dans les versions plus récentes. Intel a divulgué les failles CVE suivantes : Ces failles CVE sont collectivement désignées par l'appellation "Microarchitectural Data Sampling (MDS)". En raison de l'interaction entre l'exécution spéculative et l'état microarchitectural, elles comportent un risque d'exposition des données. Pour en savoir plus, consultez le communiqué d'Intel. L'infrastructure hôte qui exécute Kubernetes Engine isole les charges de travail des clients les unes des autres. Vous n'êtes pas affecté à moins que vous n'exécutiez du code non approuvé dans vos propres clusters GKE mutualisés. Cette faille s'avère particulièrement grave pour les clients qui exécutent du code non approuvé au sein de leurs propres services mutualisés dans Kubernetes Engine. Pour limiter les risques engendrés dans Kubernetes Engine, désactivez l'Hyper-Threading dans vos nœuds. Seuls les nœuds Google Kubernetes Engine (GKE) utilisant plusieurs processeurs sont affectés par ces failles. Notez que les VM n1-standard-1 (type de machine GKE par défaut), g1-small et f1-micro n'exposent qu'un processeur virtuel à l'environnement invité. Il n'est donc pas nécessaire de désactiver l'Hyper-Threading. D'autres protections permettant d'activer la fonctionnalité de vidage seront intégrées à une prochaine version du correctif. Nous mettrons automatiquement à niveau les instances maîtres et les nœuds vers la version corrigée au cours des prochaines semaines, selon le rythme de mise à niveau habituel. Le correctif ne permet pas, à lui seul, de limiter l'exposition à cette faille. Pour connaître les actions recommandées, consultez les informations ci-dessous. Si vous exécutez GKE On-Prem, vous pouvez être affecté selon le matériel que vous utilisez. Veuillez vous reporter au communiqué d'Intel. Que dois-je faire ?Vous n'êtes pas affecté à moins que vous n'exécutiez du code non approuvé dans vos propres clusters GKE mutualisés. Pour les nœuds s'exécutant dans Kubernetes Engine, créez des pools de nœuds en désactivant l'Hyper-Threading et reprogrammez vos charges de travail sur les nouveaux nœuds. Notez que les VM n1-standard-1, g1-small et f1-micro n'exposent qu'un processeur virtuel à l'environnement invité. Il n'est donc pas nécessaire de désactiver l'Hyper-Threading. Avertissement :
Pour créer un pool de nœuds en désactivant l'Hyper-Threading, procédez comme suit :
Le DaemonSet doit rester en cours d'exécution sur le pool de nœuds pour que les modifications soient automatiquement appliquées aux nœuds qui seront créés dans le pool. Des créations de nœuds peuvent être déclenchées par les processus de réparation automatique, de mise à niveau manuelle ou automatique, et d'autoscaling des nœuds. Pour réactiver l'Hyper-Threading, vous devez recréer le pool de nœuds sans déployer le DaemonSet fourni, puis migrer vos charges de travail vers le nouveau pool. Nous vous recommandons également de mettre à niveau manuellement les nœuds une fois que le correctif sera disponible. Avant tout, vous devez mettre à niveau votre instance maître vers la version la plus récente. Les instances maîtres de GKE seront automatiquement mises à niveau au rythme habituel. Nous mettrons à jour ce bulletin en y ajoutant les versions contenant un correctif une fois qu'elles seront disponibles. Quelles failles ce correctif permet-il de résoudre ?Ce correctif réduit les risques liés aux failles suivantes : CVE-2018-12126, CVE-2018-12127, CVE-2018-12130 et CVE-2019-11091 : ces failles exploitent l'exécution spéculative. Ces failles CVE sont collectivement désignées par l'appellation "Microarchitectural Data Sampling". En raison de l'interaction entre l'exécution spéculative et l'état microarchitectural, elles comportent un risque d'exposition des données. |
Moyen |
5 avril 2019
Description | Gravité | Remarques |
---|---|---|
Les failles de sécurité CVE-2019-9900 et CVE-2019-9901 ont été récemment découvertes dans Envoy. Istio intègre Envoy, et ces failles permettent le contournement de la règle Istio dans certains cas. Si vous avez activé Istio sur Google Kubernetes Engine (GKE), vous pouvez être affecté par ces failles. Nous vous recommandons de mettre à niveau le plus rapidement possible les clusters affectés vers la dernière version du correctif, de même que les side-cars Istio (voir les instructions ci-dessous). Que dois-je faire ?En raison de la gravité de ces failles, que la mise à niveau automatique des nœuds soit activée ou non, nous vous recommandons d'exécuter les opérations suivantes :
Les versions corrigées seront mises à disposition pour tous les projets GKE aujourd'hui avant 19:00 PDT. Ce correctif sera disponible dans les versions de GKE qui sont indiquées ci-dessous. Les nouveaux clusters utiliseront par défaut les versions corrigées à compter de l'annonce de celles-ci sur la page des bulletins de sécurité de GKE, laquelle doit avoir lieu le 15 avril 2019. Si vous créez un cluster avant cette date, vous devrez spécifier la version corrigée pour qu'il l'utilise. Les clients GKE qui ont activé la mise à niveau automatique des nœuds et qui ne procèdent pas à des mises à niveau manuelles seront mis à jour automatiquement vers les versions corrigées au cours de la semaine suivante. Versions corrigées :
Quelles failles ce correctif permet-il de résoudre ?Ce correctif réduit les risques liés aux failles suivantes : CVE-2019-9900 et CVE-2019-9901. Pour en savoir plus sur ces failles, consultez le blog Istio. |
Élevé |
1er mars 2019
Description | Gravité | Remarques |
---|---|---|
Mise à jour du 22/03/2019 : ce correctif est disponible dans Kubernetes 1.11.8-gke.4 et 1.13.4-gke.1, ainsi que dans les versions plus récentes. Il n'est pas encore inclus dans la version 1.12. Pour vérifier sa disponibilité, consultez les notes de version. La communauté Kubernetes a récemment découvert une nouvelle faille par déni de service, CVE-2019-1002100. Celle-ci permet à un utilisateur autorisé à envoyer des requêtes "patch" de créer une requête "json-patch" malveillante. Cette requête surutilise le processeur et la mémoire du serveur d'API Kubernetes, ce qui peut limiter la disponibilité du plan de contrôle du cluster. Pour en savoir plus, consultez le communiqué de Kubernetes. Cette faille affecte l'ensemble des instances maîtres de Google Kubernetes Engine (GKE). Une prochaine version du correctif permettra de limiter les risques liés à cette faille. Nous mettrons automatiquement à niveau les instances maîtres du cluster vers la version corrigée au cours des prochaines semaines, selon le rythme de mise à niveau habituel. Que dois-je faire ?Aucune action n'est requise. Les instances maîtres de GKE seront automatiquement mises à niveau au rythme habituel. Pour accélérer le processus, vous pouvez lancer manuellement la mise à niveau d'une instance maître. Nous mettrons à jour ce bulletin en y ajoutant les versions contenant un correctif. Notez que le correctif ne sera pas proposé dans la version 1.10. Il ne sera disponible que dans les versions 1.11 et ultérieures. Quelle est la faille prise en charge par ce correctif ?Ce correctif réduit les risques liés à la faille suivante : La faille CVE-2019-1002100 permet à un utilisateur de créer spécifiquement un correctif de type "json-patch" qui surutilise le processeur du serveur d'API Kubernetes, ce qui peut limiter la disponibilité du plan de contrôle du cluster. |
Moyen | CVE-2019-1002100 |
11 février 2019 (runc)
Description | Gravité | Remarques |
---|---|---|
L'Open Containers Initiative (OCI) a récemment découvert une nouvelle faille de sécurité (CVE-2019-5736) dans runc. Celle-ci permet de "s'échapper d'un conteneur" pour obtenir un accès root (racine) sur le nœud hôte. Cette faille affecte les nœuds Ubuntu dans Google Kubernetes Engine (GKE). Nous vous recommandons donc d'effectuer dès que possible une mise à niveau vers la dernière version du correctif conformément à la procédure décrite ci-dessous. Que dois-je faire ?Avant tout, vous devez mettre à niveau votre nœud maître vers la toute dernière version. Ce correctif est disponible dans Kubernetes 1.10.12-gke.7, 1.11.6-gke.11, 1.11.7-gke.4 et 1.12.5-gke.5, ainsi que dans les versions plus récentes. Pour vérifier sa disponibilité, consultez les notes de version. Sachez que seuls les nœuds Ubuntu dans GKE sont affectés. Les nœuds exécutant COS ne sont pas concernés. Sachez que la nouvelle version de runc nécessite davantage de mémoire. Vous devrez donc peut-être mettre à niveau la mémoire allouée aux conteneurs si vous avez défini des limites de mémoire peu élevées (< 16 Mo). Quelle est la faille prise en charge par ce correctif ?Ce correctif réduit les risques liés à la faille suivante : La faille CVE-2019-5736 affecte l'environnement d'exécution de conteneurs runc. Elle permet à un conteneur malveillant d'écraser le fichier binaire runc du nœud hôte et d'accéder ainsi en écriture à son répertoire racine (root) par le biais d'un simple appel système "exec". Les conteneurs qui ne s'exécutent pas en mode root ne sont pas affectés. La gravité de cette faille est évaluée comme élevée. |
Élevé | CVE-2019-5736 |
11 février 2019 (Go)
Description | Gravité | Remarques |
---|---|---|
Mise à jour du 25/02/2019 : comme indiqué précédemment, le correctif n'est pas disponible dans 1.11.7-gke.4. Si vous exécutez la version 1.11.7, vous pouvez revenir à la version 1.11.6, procéder à la mise à niveau vers la version 1.12 ou attendre que le prochain correctif de la version 1.11.7 soit mis à disposition la semaine du 04/03/2019. Le langage de programmation Go a récemment découvert une nouvelle faille de sécurité, CVE-2019-6486. Il s'agit d'une faille par déni de service (DoS) dans les mises en œuvre de cryptographie sur les courbes elliptiques P-521 et P-384. Dans Google Kubernetes Engine (GKE), elle peut permettre à un utilisateur de créer des requêtes malveillantes qui surutilisent le processeur du serveur de l'API Kubernetes, ce qui peut réduire la disponibilité du plan de contrôle du cluster. Pour en savoir plus, consultez le communiqué sur le langage de programmation Go. Cette faille affecte l'ensemble des instances maîtres de Google Kubernetes Engine (GKE). La dernière version du correctif permet de limiter les risques qu'elle engendre. Nous mettrons automatiquement à niveau les maîtres de cluster vers la version incluant le correctif au cours des prochaines semaines, selon le rythme de mise à niveau habituel. Que dois-je faire ?Aucune action n'est requise. Les instances maîtres de GKE seront automatiquement mises à niveau au rythme habituel. Pour accélérer le processus, vous pouvez lancer manuellement la mise à niveau d'une instance maître. Ce correctif est disponible dans GKE 1.10.12-gke.7, 1.11.6-gke.11, 1.11.7-gke.4 et 1.12.5-gke.5, ainsi que dans les versions plus récentes. Quelle est la faille prise en charge par ce correctif ?Ce correctif réduit les risques liés à la faille suivante : La faille CVE-2019-6486 affecte les mises en œuvre de cryptographie sur les courbes elliptiques P-521 et P-384. Elle permet à un utilisateur de créer des entrées qui surutilisent le processeur. |
Élevé | CVE-2019-6486 |
3 décembre 2018
Description | Gravité | Remarques |
---|---|---|
Kubernetes a récemment découvert une nouvelle faille de sécurité, CVE-2018-1002105, qui permet à un utilisateur disposant d'un niveau de privilèges relativement faible de contourner les autorisations d'accès aux API du kubelet. Par conséquent, cet utilisateur peut exécuter des opérations arbitraires pour tous les pods sur n'importe quel nœud du cluster. Pour en savoir plus, consultez le communiqué de Kubernetes. Cette faille affectait l'ensemble des instances maîtres de Google Kubernetes Engine (GKE), et nous avons déjà procédé à la mise à niveau des clusters vers les dernières versions du correctif. Aucune action n'est requise. Que dois-je faire ?Aucune action n'est requise. Les instances maîtres de GKE ont déjà été mises à niveau. Ce correctif est disponible dans GKE 1.9.7-gke.11, 1.10.6-gke.11, 1.10.7-gke.11, 1.10.9-gke.5 et 1.11.2-gke.18 ainsi que dans les versions plus récentes. Quelle est la faille prise en charge par ce correctif ?Ce correctif réduit les risques liés à la faille suivante : La faille CVE-2018-1002105 permet à un utilisateur disposant d'un niveau de privilèges relativement faible de contourner les autorisations d'accès aux API du kubelet. Un utilisateur autorisé à effectuer des requêtes de mise à niveau peut ainsi obtenir une élévation de privilège et envoyer des appels arbitraires aux API du kubelet. Cette faille de Kubernetes est considérée comme critique. Au vu de certaines informations concernant la mise en œuvre de GKE qui empêchaient les élévations de privilège non authentifiées, cette vulnérabilité est considérée comme une faille de sécurité de gravité élevée. |
Élevé | CVE-2018-1002105 |
13 novembre 2018
Description |
---|
Mise à jour du 16 novembre 2018 : la révocation et la rotation de tous les jetons potentiellement impactés sont terminées. Aucune action supplémentaire n'est requise. Google a récemment détecté un problème dans le plug-in CNI (Container Network Interface) Calico qui peut, dans certaines configurations, consigner des informations sensibles. Référence de suivi du problème : Tigera Technical Advisory TTA-2018-001.
Ces jetons disposent des autorisations suivantes : |
bgpconfigurations.crd.projectcalico.org [create get list update watch] bgppeers.crd.projectcalico.org [create get list update watch] clusterinformations.crd.projectcalico.org [create get list update watch] felixconfigurations.crd.projectcalico.org [create get list update watch] globalbgpconfigs.crd.projectcalico.org [create get list update watch] globalfelixconfigs.crd.projectcalico.org [create get list update watch] globalnetworkpolicies.crd.projectcalico.org [create get list update watch] globalnetworksets.crd.projectcalico.org [create get list update watch] hostendpoints.crd.projectcalico.org [create get list update watch] ippools.crd.projectcalico.org [create get list update watch] networkpolicies.crd.projectcalico.org [create get list update watch] nodes [get list update watch] pods [get list watch patch] namespaces [get list watch] networkpolicies.extensions [get list watch] endpoints [get] services [get] pods/status [update] networkpolicies.networking.k8s.io [watch list] |
Les clusters Google Kubernetes Engine sur lesquels une stratégie de réseau de cluster et Stackdriver Logging sont activés ont consigné les jetons de compte de service Calico dans Stackdriver. Les clusters sur lesquels aucune stratégie de réseau de cluster n'est activée ne sont pas affectés.
Nous avons déployé un correctif qui migre le plug-in CNI Calico afin que ce dernier n'effectue la journalisation qu'au niveau d'avertissement et qu'il utilise un nouveau compte de service. Le code Calico corrigé sera déployé dans une version ultérieure.
Au cours de la semaine prochaine, nous allons effectuer une révocation progressive de tous les jetons potentiellement impactés. Ce bulletin sera mis à jour dès que la révocation sera terminée. Aucune action supplémentaire de votre part n'est nécessaire. (Cette rotation est terminée depuis le 16 novembre 2018.)
Si vous souhaitez révoquer ces jetons immédiatement, vous pouvez exécuter la commande ci-dessous. Le nouveau secret du compte de service devrait être recréé automatiquement en quelques secondes :
kubectl get sa --namespace kube-system calico -o template --template '{{(index .secrets 0).name}}' | xargs kubectl delete secret --namespace kube-system |
DétectionLes journaux GKE accèdent tous au serveur d'API. Pour déterminer si un jeton Calico a été utilisé depuis une plage d'adresses IP autre que celle prévue par Google Cloud, vous pouvez exécuter la requête Stackdriver suivante. Veuillez noter que cette commande ne renverra des enregistrements que pour les appels effectués en dehors du réseau GCP. Il est conseillé de la personnaliser selon les besoins de votre environnement spécifique. |
resource.type="k8s_cluster" protoPayload.authenticationInfo.principalEmail="system:serviceaccount:kube-system:calico" NOT ip_in_net(protoPayload.requestMetadata.callerIp, "8.34.208.0/20") NOT ip_in_net(protoPayload.requestMetadata.callerIp, "8.35.192.0/21") NOT ip_in_net(protoPayload.requestMetadata.callerIp, "8.35.200.0/23") NOT ip_in_net(protoPayload.requestMetadata.callerIp, "108.59.80.0/20") NOT ip_in_net(protoPayload.requestMetadata.callerIp, "108.170.192.0/20") NOT ip_in_net(protoPayload.requestMetadata.callerIp, "108.170.208.0/21") NOT ip_in_net(protoPayload.requestMetadata.callerIp, "108.170.216.0/22") NOT ip_in_net(protoPayload.requestMetadata.callerIp, "108.170.220.0/23") NOT ip_in_net(protoPayload.requestMetadata.callerIp, "108.170.222.0/24") NOT ip_in_net(protoPayload.requestMetadata.callerIp, "35.224.0.0/13") NOT ip_in_net(protoPayload.requestMetadata.callerIp, "162.216.148.0/22") NOT ip_in_net(protoPayload.requestMetadata.callerIp, "162.222.176.0/21") NOT ip_in_net(protoPayload.requestMetadata.callerIp, "173.255.112.0/20") NOT ip_in_net(protoPayload.requestMetadata.callerIp, "192.158.28.0/22") NOT ip_in_net(protoPayload.requestMetadata.callerIp, "199.192.112.0/22") NOT ip_in_net(protoPayload.requestMetadata.callerIp, "199.223.232.0/22") NOT ip_in_net(protoPayload.requestMetadata.callerIp, "199.223.236.0/23") NOT ip_in_net(protoPayload.requestMetadata.callerIp, "23.236.48.0/20") NOT ip_in_net(protoPayload.requestMetadata.callerIp, "23.251.128.0/19") NOT ip_in_net(protoPayload.requestMetadata.callerIp, "35.204.0.0/14") NOT ip_in_net(protoPayload.requestMetadata.callerIp, "35.208.0.0/13") NOT ip_in_net(protoPayload.requestMetadata.callerIp, "107.167.160.0/19") NOT ip_in_net(protoPayload.requestMetadata.callerIp, "107.178.192.0/18") NOT ip_in_net(protoPayload.requestMetadata.callerIp, "146.148.2.0/23") NOT ip_in_net(protoPayload.requestMetadata.callerIp, "146.148.4.0/22") NOT ip_in_net(protoPayload.requestMetadata.callerIp, "146.148.8.0/21") NOT ip_in_net(protoPayload.requestMetadata.callerIp, "146.148.16.0/20") NOT ip_in_net(protoPayload.requestMetadata.callerIp, "146.148.32.0/19") NOT ip_in_net(protoPayload.requestMetadata.callerIp, "146.148.64.0/18") NOT ip_in_net(protoPayload.requestMetadata.callerIp, "35.203.0.0/17") NOT ip_in_net(protoPayload.requestMetadata.callerIp, "35.203.128.0/18") NOT ip_in_net(protoPayload.requestMetadata.callerIp, "35.203.192.0/19") NOT ip_in_net(protoPayload.requestMetadata.callerIp, "35.203.240.0/20") NOT ip_in_net(protoPayload.requestMetadata.callerIp, "130.211.8.0/21") NOT ip_in_net(protoPayload.requestMetadata.callerIp, "130.211.16.0/20") NOT ip_in_net(protoPayload.requestMetadata.callerIp, "130.211.32.0/19") NOT ip_in_net(protoPayload.requestMetadata.callerIp, "130.211.64.0/18") NOT ip_in_net(protoPayload.requestMetadata.callerIp, "130.211.128.0/17") NOT ip_in_net(protoPayload.requestMetadata.callerIp, "104.154.0.0/15") NOT ip_in_net(protoPayload.requestMetadata.callerIp, "104.196.0.0/14") NOT ip_in_net(protoPayload.requestMetadata.callerIp, "208.68.108.0/23") NOT ip_in_net(protoPayload.requestMetadata.callerIp, "35.184.0.0/14") NOT ip_in_net(protoPayload.requestMetadata.callerIp, "35.188.0.0/15") NOT ip_in_net(protoPayload.requestMetadata.callerIp, "35.202.0.0/16") NOT ip_in_net(protoPayload.requestMetadata.callerIp, "35.190.0.0/17") NOT ip_in_net(protoPayload.requestMetadata.callerIp, "35.190.128.0/18") NOT ip_in_net(protoPayload.requestMetadata.callerIp, "35.190.192.0/19") NOT ip_in_net(protoPayload.requestMetadata.callerIp, "35.235.224.0/20") NOT ip_in_net(protoPayload.requestMetadata.callerIp, "35.192.0.0/14") NOT ip_in_net(protoPayload.requestMetadata.callerIp, "35.196.0.0/15") NOT ip_in_net(protoPayload.requestMetadata.callerIp, "35.198.0.0/16") NOT ip_in_net(protoPayload.requestMetadata.callerIp, "35.199.0.0/17") NOT ip_in_net(protoPayload.requestMetadata.callerIp, "35.199.128.0/18") NOT ip_in_net(protoPayload.requestMetadata.callerIp, "35.200.0.0/15") NOT ip_in_net(protoPayload.requestMetadata.callerIp, "2600:1900::/35") NOT ip_in_net(protoPayload.requestMetadata.callerIp, "35.190.224.0/20") NOT ip_in_net(protoPayload.requestMetadata.callerIp, "35.232.0.0/15") NOT ip_in_net(protoPayload.requestMetadata.callerIp, "35.234.0.0/16") NOT ip_in_net(protoPayload.requestMetadata.callerIp, "35.235.0.0/17") NOT ip_in_net(protoPayload.requestMetadata.callerIp, "35.235.192.0/20") NOT ip_in_net(protoPayload.requestMetadata.callerIp, "35.236.0.0/14") NOT ip_in_net(protoPayload.requestMetadata.callerIp, "35.240.0.0/15") NOT ip_in_net(protoPayload.requestMetadata.callerIp, "35.203.232.0/21") NOT ip_in_net(protoPayload.requestMetadata.callerIp, "130.211.4.0/22") NOT ip_in_net(protoPayload.requestMetadata.callerIp, "35.220.0.0/14") NOT ip_in_net(protoPayload.requestMetadata.callerIp, "35.242.0.0/15") NOT ip_in_net(protoPayload.requestMetadata.callerIp, "35.244.0.0/14") |
14 août 2018
Description | Gravité | Remarques |
---|---|---|
Intel a divulgué les failles CVE suivantes :
Ces failles CVE sont collectivement désignées sous le nom de "L1 Terminal Fault (L1TF)". Ces failles L1TF exploitent l'exécution spéculative en attaquant la configuration des structures de données au niveau du processeur. "L1" fait référence au cache des données L1D (Level-1 Data), une petite ressource sur le cœur qui permet d'accélérer l'accès à la mémoire. Lisez cet article du blog Google Cloud pour en savoir plus sur ces failles et les protections de Compute Engine. Impact sur Google Kubernetes EngineL'infrastructure qui exécute Kubernetes Engine, et qui isole les clusters et les nœuds client les uns des autres, est protégée contre les attaques connues. Les pools de nœuds Kubernetes Engine qui utilisent l'image Container-Optimized OS (COS) de Google et pour lesquels la mise à niveau automatique est activée seront automatiquement mis à niveau vers les versions corrigées de notre image COS. Ces versions seront disponibles dès le 20 août 2018. Les pools de nœuds Kubernetes Engine pour lesquels la mise à niveau automatique n'est pas activée devront être manuellement mis à niveau dès que les versions corrigées de notre image COS seront disponibles. |
Élevé |
6 août 2018 (dernière mise à jour le 5 septembre 2018)
Description | Gravité | Remarques |
---|---|---|
Mise à jour du 05/09/2018La faille CVE-2018-5391 a été divulguée récemment. Tout comme CVE-2018-5390, il s'agit d'une faille réseau au niveau du noyau. Celle-ci rend les attaques par déni de service (DoS) plus efficaces dans les systèmes vulnérables. La principale différence réside dans le fait que la faille CVE-2018-5391 est exploitable sur les connexions IP. Nous avons mis à jour ce bulletin afin de traiter de ces deux failles. DescriptionCVE-2018-5390 ("SegmentSmack") fait référence à une faille réseau au niveau du noyau. Celle-ci rend les attaques de déni de service (DOS) plus efficaces dans les systèmes vulnérables, via les connexions TCP. CVE-2018-5391 ("FragmentSmack") fait référence à une faille réseau au niveau du noyau. Celle-ci rend les attaques de déni de service (DOS) plus efficaces dans les systèmes vulnérables, via les connexions IP. Impact sur Google Kubernetes EngineDepuis le 11 août 2018, toutes les instances maîtresses de Kubernetes Engine sont protégées contre ces deux failles. Par ailleurs, tous les clusters Kubernetes Engine qui ont été configurés pour être mis à niveau automatiquement sont également protégés contre ces deux failles. Les pools de nœuds Kubernetes Engine qui ne sont pas configurés pour être mis à niveau automatiquement, et qui ont été mis à niveau manuellement pour la dernière fois avant le 11 août 2018, sont affectés par ces deux failles. Versions corrigéesEn raison de la gravité de cette faille, nous vous recommandons de mettre à niveau manuellement vos nœuds dès que le correctif sera disponible. |
Élevé |
30 mai 2018
Description | Gravité | Remarques |
---|---|---|
Une faille a récemment été détectée dans Git. Celle-ci peut entraîner l'élévation des privilèges dans Kubernetes si des utilisateurs non privilégiés sont autorisés à créer des pods avec des volumes gitRepo. La faille CVE est identifiée par le tag CVE-2018-11235. Suis-je concerné ?Cette faille vous concerne si toutes les affirmations suivantes s'appliquent à votre cas :
Tous les nœuds Kubernetes Engine sont vulnérables. Que dois-je faire ?
Interdisez l'utilisation du type de volume gitRepo. Pour effectuer cette opération avec PodSecurityPolicy, omettez Il est possible d'obtenir un comportement équivalent au volume "gitRepo" en clonant un dépôt Git dans un volume "EmptyDir" à partir d'un conteneur "initContainer" :
Quel correctif résout cette faille ?Un correctif sera intégré à une version ultérieure de Kubernetes Engine. Revenez consulter cette page pour en savoir plus. |
Moyen |
21 mai 2018
Description | Gravité | Remarques |
---|---|---|
Plusieurs failles ont été détectées récemment dans le noyau Linux. Elles peuvent entraîner l'élévation des privilèges ou le déni de service (via le plantage du noyau) à partir d'un processus non privilégié. Ces failles CVE sont identifiées par les tags CVE-2018-1000199, CVE-2018-8897 et CVE-2018-1087. Tous les nœuds Kubernetes Engine sont affectés par ces failles. Nous vous recommandons donc d'effectuer une mise à niveau vers la dernière version du correctif conformément à la procédure ci-dessous. Que dois-je faire ?Avant tout, vous devez mettre à niveau votre instance maître vers la toute dernière version. Ce correctif est disponible dans Kubernetes Engine 1.8.12-gke.1, Kubernetes Engine 1.9.7-gke.1 et Kubernetes Engine 1.10.2-gke.1. Ces versions incluent des correctifs pour les images OS optimisées pour les conteneurs et Ubuntu. Si vous créez un nouveau cluster avant la mise à niveau vous devez spécifier la version corrigée avec laquelle il doit être utilisé. Les clients qui ont activé la mise à niveau automatique des nœuds et qui ne procèdent pas à une mise à niveau manuelle verront leurs nœuds mis à niveau vers les versions corrigées dans les prochaines semaines. Quelles failles ce correctif permet-il de résoudre ?Ce correctif réduit les risques liés aux failles suivantes : CVE-2018-1000199 : Cette faille affecte le noyau Linux. Elle permet à un utilisateur ou à un processus non privilégié d'entraîner le plantage du noyau du système, ce qui conduit à une attaque DoS ou à une élévation des privilèges. La gravité de cette faille est évaluée comme élevée, et son score CVSS est de 7,8. CVE-2018-8897 : Cette faille affecte le noyau Linux. Elle permet à un utilisateur ou à un processus non privilégié d'entraîner le plantage du noyau du système, ce qui conduit à une attaque DoS. La gravité de cette faille est évaluée comme moyenne, et son score CVSS est de 6,5. CVE-2018-1087 : Cette faille affecte l'hyperviseur KVM du noyau Linux. Elle permet à un processus non privilégié d'entraîner le plantage du noyau invité ou, potentiellement, d'obtenir des privilèges. Cette faille est résolue dans l'infrastructure sur laquelle s'exécute Kubernetes Engine. Ce dernier n'est donc pas affecté. La gravité de cette faille est évaluée comme élevée, et son score CVSS est de 8,0. |
Élevé |
12 mars 2018
Description | Gravité | Remarques |
---|---|---|
Le projet Kubernetes a récemment divulgué de nouvelles failles de sécurité, CVE-2017-1002101 et CVE-2017-1002102, qui permettent à un conteneur d'accéder aux fichiers situés en dehors de celui-ci. Tous les nœuds Kubernetes Engine sont affectés par ces failles. Nous vous recommandons donc d'effectuer dès que possible une mise à niveau vers la dernière version munie du correctif. La procédure de mise à niveau est expliquée ci-dessous. Que dois-je faire ?En raison de la gravité de ces failles, que la mise à niveau automatique des nœuds soit activée ou non, nous vous recommandons de mettre à niveau manuellement vos nœuds dès que le correctif est disponible. Celui-ci sera mis à la disposition de tous les clients au plus tard le 16 mars. Toutefois, en fonction du calendrier des lancements, vous pourriez avoir accès à ce correctif plus tôt, selon la zone dans laquelle se trouve votre cluster. Avant tout, vous devez mettre à niveau votre instance maître vers la toute dernière version. Ce correctif sera disponible dans Kubernetes 1.9.4-gke.1, Kubernetes 1.8.9-gke.1 et Kubernetes 1.7.14-gke.1. Par défaut, à compter du 30 mars, les nouveaux clusters utiliseront la version corrigée. Toutefois, si vous créez un nouveau cluster avant la mise à niveau, vous devrez spécifier la version corrigée avec laquelle il doit être utilisé. Les clients Kubernetes Engine qui ont activé la mise à niveau automatique des nœuds et qui ne procèdent pas à une mise à niveau manuelle verront leurs nœuds mis à niveau vers les versions corrigées d'ici le 23 avril. Toutefois, en raison de la nature de ces failles, nous vous recommandons de mettre à niveau manuellement vos nœuds dès que le correctif sera disponible. Quelles failles ce correctif permet-il de résoudre ?Ce correctif réduit les risques liés aux deux failles suivantes : La faille CVE-2017-1002101 permet aux conteneurs utilisant des montages de volume de sous-chemin d'accéder aux fichiers en dehors du volume. Par conséquent, si la stratégie "PodSecurityPolicy" empêche les conteneurs d'accéder au chemin d'accès à l'hôte, un pirate autorisé à mettre à jour ou à créer des pods peut monter un chemin d'accès à l'hôte à l'aide d'un autre type de volume. La faille CVE-2017-1002102 permet aux conteneurs utilisant certains types de volumes (y compris les secrets, les mappages de configuration, les volumes prévus ou les volumes d'API Downward) de supprimer des fichiers en dehors du volume. Par conséquent, si la sécurité d'un conteneur utilisant l'un de ces types de volumes est compromise, ou si un utilisateur non approuvé est autorisé à créer des pods, un pirate peut se servir de ce conteneur pour supprimer des fichiers arbitraires sur l'hôte. Pour en savoir plus sur ce correctif, consultez cet article sur le blog Kubernetes. |
Élevé |
Bulletins de sécurité Google Distributed Cloud
16 octobre 2019
Description | Gravité | Remarques |
---|---|---|
La faille CVE-2019-11253 a été récemment découverte dans Kubernetes. Elle permet à tout utilisateur autorisé d'effectuer des requêtes POST afin de réaliser à distance une attaque par déni de service sur un serveur d'API Kubernetes. Le comité de sécurité des produits (PSC, Product Security Committee) Kubernetes a publié des informations complémentaires sur cette faille. Pour les consulter, cliquez ici. Vous pouvez atténuer cette faille en limitant les clients disposant d'un accès réseau à vos serveurs d'API Kubernetes. Que dois-je faire ?Nous vous recommandons de mettre à jour votre cluster vers une version contenant le correctif permettant de remédier à cette faille dès sa mise à disposition. Les versions qui bénéficieront du correctif sont indiquées ci-dessous :
Quelle faille ce correctif permet-il de résoudre ?Le correctif réduit les risques liés à la faille suivante : CVE-2019-11253. |
Élevé |
23 août 2019
Description | Gravité | Remarques |
---|---|---|
Nous avons récemment découvert et corrigé une faille de sécurité : le proxy RBAC sécurisant les points de terminaison de surveillance n'autorisait pas correctement les utilisateurs. Par conséquent, les métriques de certains composants étaient à la disposition des utilisateurs non autorisés au sein du réseau de cluster interne. Les composants suivants ont été affectés :
Que dois-je faire ?Nous vous recommandons de mettre à jour vos clusters vers la version 1.0.2-gke.3, qui inclut le correctif permettant de remédier à cette faille, dès que possible. |
Moyenne |
22 août 2019
Description | Gravité | Remarques |
---|---|---|
La communauté Kubernetes a récemment découvert une faille de sécurité, CVE-2019-11247, qui permet d'intervenir sur les instances de ressources personnalisées à l'échelle d'un cluster comme s'il s'agissait d'objets présents dans tous les espaces de noms. Cela signifie que les comptes utilisateur et de service ne disposant que d'autorisations RBAC au niveau de l'espace de noms peuvent interagir avec des ressources personnalisées à l'échelle du cluster. Pour exploiter cette faille, le pirate informatique doit disposer de privilèges permettant d'accéder aux ressources de n'importe quel espace de noms. Que dois-je faire ?Nous vous recommandons de mettre à jour vos clusters vers la version 1.0.2-gke.3, qui inclut le correctif permettant de remédier à cette faille, dès que possible. Quelle faille ce correctif permet-il de résoudre ?Le correctif limite les risques liés à la faille suivante : CVE-2019-11247. |
Moyen |