Bulletins de sécurité

Tous les bulletins de sécurité relatifs à Anthos clusters on VMware (GKE On-Prem) sont décrits dans cet article.

Les failles de sécurité sont souvent gardées secrètes jusqu'à ce que les parties concernées aient eu la possibilité de les corriger. Dans ces cas, les notes de version d'Anthos clusters on VMware font référence à des "mises à jour de sécurité " jusqu'à la levée du secret. Les notes sont alors mises à jour pour refléter les failles traitées par le correctif.

Pour recevoir les derniers bulletins de sécurité concernant ce produit, ajoutez l'URL de cette page à votre lecteur de flux.

GCP-2020-015

Date de publication : 07-12-2020
Description Niveau de gravité Remarques

Le projet Kubernetes a récemment découvert une nouvelle faille de sécurité : CVE-2020-8554. Celle-ci peut permettre à un pirate informatique ayant obtenu les autorisations nécessaires pour créer un service Kubernetes de type LoadBalancer ou ClusterIP d'intercepter le trafic réseau provenant d'autres pods du cluster.

Cette faille, en elle-même, ne permet pas au pirate informatique de créer un service Kubernetes.

Tous les clusters Anthos sur VMware sont affectés par cette faille.

Que dois-je faire ?

Kubernetes devra peut-être apporter des modifications de rétrocompatibles dans une future version pour remédier à la faille.

Si de nombreux utilisateurs partagent l'accès à votre cluster avec les autorisations requises pour créer des services, par exemple dans un cluster mutualisé, envisagez d'appliquer une mesure d'atténuation. À l'heure actuelle, la meilleure approche pour l'atténuation consiste à limiter l'utilisation d'adresses IP externes dans un cluster. Les adresses IP externes ne sont pas une fonctionnalité couramment utilisée.

Limitez l'utilisation d'adresses IP externes dans un cluster avec l'une des méthodes suivantes :
  1. Utilisez Anthos Policy Controller ou GateKeeper avec ce modèle de contrainte et appliquez-le. Exemple : 
    
# Only allow the creation of Services with no
# ExternalIP or an ExternalIP of 203.0.113.1:

apiVersion: constraints.gatekeeper.sh/v1beta1
kind: K8sExternalIPs
metadata:
  name: external-ips
spec:
  match:
    kinds:
      - apiGroups: [""]
        kinds: ["Service"]
  parameters:
    allowedIPs:
      - "203.0.113.1"
  2. Vous pouvez également installer un contrôleur d'admission pour empêcher l'utilisation d'adresses IP externes. Le projet Kubernetes a fourni un exemple de contrôleur d'admission pour cette tâche.

Comme indiqué dans l'annonce Kubernetes, aucune atténuation n'est fournie pour les services de type LoadBalancer, car par défaut, seuls les utilisateurs disposant de droits les plus privilégiés et les composants du système ont l'autorisation container.services.updateStatus, nécessaire pour exploiter cette faille.

Moyen

CVE-2020-8554

GCP-2020-014

Date de publication : 20-10-2020
Dernière mise à jour : 10-10-2020
Description Niveau de gravité Remarques

Le projet Kubernetes a récemment découvert plusieurs problèmes qui permettent l'exposition des données des secrets lors de l'activation des options de journalisation détaillée. Les problèmes sont les suivants :

  • CVE-2020-8563 : fuites des secrets dans les journaux du fournisseur vSphere kube-controller-manager
  • CVE-2020-8564 : fuite des secrets de configuration Docker lorsque le fichier est mal formé, et que le niveau de journalisation est supérieur ou égal à 4.
  • CVE-2020-8565 : correction partielle de la faille CVE-2019-11250 dans Kubernetes occasionnant la divulgation des jetons dans les journaux lorsque le niveau de journalisation est supérieur ou égal à 9. Faille détectée par la sécurité de GKE.
  • CVE-2020-8566 : fuite des secrets des administrateurs Ceph RBD dans les journaux lorsque le niveau de journalisation est supérieur ou égal à 4.

GKE On-Prem n'est pas affecté.

Que dois-je faire ?

Aucune autre action n'est requise en raison des niveaux de journalisation détaillée par défaut de GKE.

Aucun

GCP-2020-012

Date de publication : 14-09-2020
Dernière mise à jour : 17-09-2020
Description Niveau de gravité Remarques

Une faille a été récemment découverte dans le noyau Linux, décrite dans CVE-2020-14386, qui permet de s'échapper d'un conteneur pour obtenir un accès root sur le nœud hôte.

Tous les nœuds Anthos clusters on VMware sont concernés.

Que dois-je faire ?

Pour résoudre cette faille, mettez à niveau votre cluster vers une version incluant le correctif. Les versions futures d'Anthos clusters on VMware suivantes corrigeront le problème, et ce bulletin sera mis à jour dès qu'elles seront disponibles :

  • Anthos clusters on VMware 1.4.3 est désormais disponible.
  • Anthos clusters on VMware 1.3.4 est désormais disponibles.

L'exploitation de cette faille nécessite CAP_NET_RAW, mais généralement peu de conteneurs nécessitent CAP_NET_RAW. Il faut donc la bloquer par défaut, ainsi que d'autres fonctionnalités puissantes, via PodSecurityPolicy ou Policy Controller :

Supprimez la fonctionnalité CAP_NET_RAW des conteneurs à l'aide de l'une des méthodes suivantes :

  • Appliquez le blocage de ces fonctionnalités avec PodSecurityPolicy, par exemple :
    
      # Require dropping CAP_NET_RAW with a PSP
      apiversion: extensions/v1beta1
      kind: PodSecurityPolicy
      metadata:
        name: no-cap-net-raw
      spec:
        requiredDropCapabilities:
          -NET_RAW
           ...
           # Unrelated fields omitted
  • Ou en utilisant Policy Controller ou Gatekeeper avec ce modèle de contrainte et en l'appliquant, par exemple :
    
      # Dropping CAP_NET_RAW with Gatekeeper
      # (requires the K8sPSPCapabilities template)
      apiversion: constraints.gatekeeper.sh/v1beta1
      kind:  K8sPSPCapabilities
      metadata:
        name: forbid-cap-net-raw
      spec:
        match:
          kinds:
            - apiGroups: [""]
            kinds: ["Pod"]
          namespaces:
            #List of namespaces to enforce this constraint on
            - default
          # If running gatekeeper >= v3.1.0-beta.5,
          # you can exclude namespaces rather than including them above.
          excludedNamespaces:
            - kube-system
        parameters:
          requiredDropCapabilities:
            - "NET_RAW"
  • Ou en mettant à jour les spécifications du pod :
    
      # Dropping CAP_NET_RAW from a Pod:
      apiVersion: v1
      kind: Pod
      metadata:
        name: no-cap-net-raw
      spec:
        containers:
          -name: my-container
           ...
          securityContext:
            capabilities:
              drop:
                -NET_RAW

Quelle faille ce correctif permet-il de résoudre ?

Ce correctif réduit les risques liés à la faille suivante :

La faille CVE-2020-14386, qui permet aux conteneurs avec CAP_NET_RAW
d'écrire de 1 à 10 octets de mémoire du noyau et éventuellement d'échapper le conteneur et d'obtenir des privilèges racine sur le nœud hôte. La gravité de cette faille est évaluée comme élevée.

Élevé

CVE-2020-14386

GCP-2020-011

Date de publication : 2020-07-24
Description Niveau de gravité Remarques

Une faille réseau, CVE-2020-8558, a été récemment détectée dans Kubernetes. Les services communiquent parfois avec d'autres applications s'exécutant dans le même pod à l'aide de l'interface de rebouclage local (127.0.0.1). Cette faille permet à un pirate informatique ayant accès au réseau du cluster d'envoyer du trafic à l'interface de rebouclage des pods et nœuds adjacents. Les services reposant sur l'interface de rebouclage et non accessibles en dehors de leur pod peuvent être exploités.

Que dois-je faire ?

Pour résoudre cette faille, mettez à niveau votre cluster vers une version incluant le correctif. Les versions Anthos clusters on VMware suivantes ou les versions ultérieures contiennent le correctif corrigé pour cette faille:

  • Anthos clusters on VMware 1.4.1
  • Anthos clusters on VMware 1.3.5

Quelle faille ce correctif permet-il de résoudre ?

Ce correctif résout la faille suivante : CVE-2020-8558.

Moyen

CVE-2020-8558

GCP-2020-009

Date de publication : 2020-07-15
Description Niveau de gravité Remarques

Une faille d'élévation des privilèges, CVE-2020-8559, a été récemment détectée dans Kubernetes. Cette faille permet à un pirate informatique ayant déjà compromis un nœud d'exécuter une commande dans n'importe quel pod du cluster. Le pirate peut ainsi utiliser le nœud déjà compromis pour en compromettre d'autres et potentiellement lire des informations, ou provoquer des actions de destruction.

Notez que pour qu'un pirate informatique puisse exploiter cette faille, un nœud de votre cluster doit déjà avoir été compromis. Cette faille, en elle-même, ne compromettra pas les nœuds de votre cluster.

Que dois-je faire ?

Mettez à niveau votre cluster vers une version corrigée. Les versions à venir Anthos clusters on VMware suivantes ou les versions ultérieures contiennent le correctif corrigé pour cette faille:

  • Anthos 1.3.3
  • Anthos 1.4.1

Quelle faille ce correctif permet-il de résoudre ?

Ce correctif réduit les risques liés à la faille CVE-2020-8559. La gravité de cette faille est évaluée comme moyenne pour GKE, car elle nécessite que le pirate informatique ait préalablement reçu des informations personnelles sur le cluster, les nœuds et les charges de travail pour réaliser efficacement cette attaque en plus de disposer d'un nœud compromis. Cette faille en elle-même ne fournit pas un nœud compromis au pirate informatique.

Moyen

CVE-2020-8559

GCP-2020-007

Date de publication : 2020-06-01
Description Niveau de gravité Remarques

La faille SSRF (Server Side Request Forgery) CVE-2020-8555 a été détectée dans Kubernetes. Elle permet à certains utilisateurs autorisés de divulguer jusqu'à 500 octets d'informations sensibles à partir du réseau hôte du plan de contrôle. Le plan de contrôle de Google Kubernetes Engine (GKE) utilise des contrôleurs Kubernetes. Il est donc concerné par cette faille. Nous vous recommandons de mettre à niveau le plan de contrôle en installant la dernière version du correctif, conformément à la procédure expliquée ci-dessous. Il n'est pas nécessaire de mettre à niveau le nœud.

Que dois-je faire ?

Les versions d'Anthos clusters on VMware suivantes ou des versions ultérieures contiennent le correctif pour cette faille :

  • Anthos 1.3.0

Si vous utilisez une version précédente, mettez à niveau votre cluster existant vers une version bénéficiant du correctif.

Quelle faille ce correctif permet-il de résoudre ?

Ce correctif réduit les risques liés à la faille CVE-2020-8555. La gravité de cette faille est évaluée comme moyenne pour GKE, car elle était difficile à exploiter en raison des diverses mesures de renforcement des plans de contrôle.

Un pirate informatique autorisé à créer un pod avec certains types de volumes intégrés (comme GlusterFS, Quobyte, StorageFS ou ScaleIO) ou à créer un objet StorageClass, peut activer l'envoi de requêtes GET ou POST par kube-controller-manager sans que le corps de la requête contrôlée par le pirate provienne du réseau hôte du maître. Ces types de volumes étant rarement employés sur GKE, leur utilisation récente constitue un bon signal de détection.

Associés à des moyens permettant de partager les résultats de la commande GET/POST avec le pirate (via des journaux, par exemple), ils peuvent entraîner la divulgation d'informations sensibles. Nous avons mis à jour les pilotes de stockage concernés afin de supprimer les risques de telles divulgations.

Moyen

CVE-2020-8555

GCP-2020-006

Date de publication : 2020-06-01
Description Niveau de gravité Remarques

Kubernetes a divulgué une faille qui permet à un conteneur privilégié de rediriger le trafic de nœuds vers un autre conteneur. Le trafic TLS/SSH mutuel (entre le kubelet et le serveur d'API, ou en provenance d'applications via le protocole mTLS) ne peut pas être lu ni modifié par cette attaque. Tous les nœuds Google Kubernetes Engine (GKE) sont affectés par cette faille. Par conséquent, nous vous recommandons de procéder à la mise à niveau en installant la dernière version du correctif, conformément à la procédure expliquée ci-dessous.

Que dois-je faire ?

Pour atténuer cette faille pour Anthos clusters on VMware (GKE On-Prem), mettez à niveau les clusters vers la version suivante ou une version plus récente :
  • Anthos 1.3.2

Très peu de conteneurs nécessitent généralement CAP_NET_RAW. Il faut donc la bloquer par défaut, ainsi que d'autres fonctionnalités puissantes, via Anthos Policy Controller ou en mettant à jour les spécifications du pod :

Supprimez la fonctionnalité CAP_NET_RAW des conteneurs à l'aide de l'une des méthodes suivantes :

  • Appliquez le blocage de ces fonctionnalités avec PodSecurityPolicy, par exemple :
    
      # Require dropping CAP_NET_RAW with a PSP
      apiversion: extensions/v1beta1
      kind: PodSecurityPolicy
      metadata:
        name: no-cap-net-raw
      spec:
        requiredDropCapabilities:
          -NET_RAW
           ...
           # Unrelated fields omitted
  • Ou en utilisant Policy Controller ou Gatekeeper avec ce modèle de contrainte et en l'appliquant, par exemple :
    
      # Dropping CAP_NET_RAW with Gatekeeper
      # (requires the K8sPSPCapabilities template)
      apiversion: constraints.gatekeeper.sh/v1beta1
      kind:  K8sPSPCapabilities
      metadata:
        name: forbid-cap-net-raw
      spec:
        match:
          kinds:
            - apiGroups: [""]
            kinds: ["Pod"]
          namespaces:
            #List of namespaces to enforce this constraint on
            - default
          # If running gatekeeper >= v3.1.0-beta.5,
          # you can exclude namespaces rather than including them above.
          excludedNamespaces:
            - kube-system
        parameters:
          requiredDropCapabilities:
            - "NET_RAW"
  • Ou en mettant à jour les spécifications du pod :
    
      # Dropping CAP_NET_RAW from a Pod:
      apiVersion: v1
      kind: Pod
      metadata:
        name: no-cap-net-raw
      spec:
        containers:
          -name: my-container
           ...
          securityContext:
            capabilities:
              drop:
                -NET_RAW

Quelle faille ce correctif permet-il de résoudre ?

Ce correctif réduit les risques liés à la faille suivante :

La faille décrite dans l'article Problème Kubernetes 91507 est liée à la fonctionnalité CAP_NET_RAW (qui fait partie de l'ensemble de fonctionnalités par défaut du conteneur). Elle configure de manière malveillante la pile IPv6 sur le nœud, et redirige le trafic de nœuds vers le conteneur contrôlé par le pirate. Cela permet au pirate d'intercepter ou de modifier le trafic en provenance du nœud ou à destination de celui-ci. Le trafic TLS/SSH mutuel (entre le kubelet et le serveur d'API, ou en provenance d'applications via le protocole mTLS) ne peut pas être lu ni modifié par cette attaque.

Moyen

Problème Kubernetes 91507

GCP-2020-004

Description Niveau de gravité Remarques

La faille CVE-2019-11254 a été récemment découverte dans Kubernetes. Elle permet à tout utilisateur autorisé d'effectuer des requêtes POST afin 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.

Vous pouvez réduire les risques liés à 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 vos clusters vers des versions contenant le correctif permettant de remédier à cette faille dès que ces versions seront disponibles.

Les versions qui contiennent le correctif sont indiquées ci-dessous :

  • Anthos 1.3.0, qui exécute la version 1.15.7-gke.32 de Kubernetes

Quelles failles ce correctif permet-il de résoudre ?

Ce correctif permet de résoudre la faille de déni de service (DoS) suivante :

CVE-2019-11254.

Moyen

CVE-2019-11254

16 octobre 2019

Description Niveau de 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 :

  • Anthos 1.1.1, qui exécute la version 1.13.7-gke.30 de Kubernetes
Quelle faille ce correctif permet-il de résoudre ?

Le correctif réduit les risques liés à la faille suivante : CVE-2019-11253.

Élevé

CVE-2019-11253

23 août 2019

Description Niveau de 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 :

  • etcd
  • etcd-events
  • kube-apiserver
  • kube-controller-manager
  • kube-scheduler
  • node-exporter
  • kube-state-metrics
  • prometheus
  • alertmanager
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.

Moyen

Versions Anthos clusters on VMware

22 août 2019

Description Niveau de 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

CVE-2019-11247