Sicherheitsbulletins

Alle Sicherheitsbulletins für GKE On-Prem werden in diesem Thema beschrieben.

Sicherheitslücken werden häufig geheim gehalten, bis die betroffenen Parteien die Möglichkeit hatten, sie zu beheben. In diesen Fällen verweisen die Versionshinweise von GKE On-Prem auf "Sicherheitsupdates", bis die Geheimhaltung aufgehoben wurde. Sobald das geschehen ist, werden die Hinweise mit Informationen über die durch den Patch behobene Sicherheitslücke aktualisiert.

Sie erhalten die neuesten Sicherheitsbulletins, wenn Sie die URL dieser Seite Ihrem Feed-Reader hinzufügen.

GCP-2020-012

Veröffentlicht: 14.09.2020
Zuletzt aktualisiert: 17.09.2020

Beschreibung Schweregrad Hinweise

Beschreibung	Schweregrad	Hinweise
Im Linux-Kernel wurde eine Sicherheitslücke entdeckt, die unter CVE-2020-14386 beschrieben ist. Damit kann Container-Escape Root-Berechtigungen für den Hostknoten erhalten. Alle GKE On-Prem-Knoten sind betroffen. Was soll ich tun? Aktualisieren Sie Ihren Cluster auf eine Patchversion, um diese Sicherheitslücke zu schließen. Die folgenden geplanten GKE On-Prem-Versionen enthalten die Korrektur dieser Sicherheitslücke. Das Bulletin wird aktualisiert, sobald sie verfügbar sind: GKE On-Prem 1.4.3, jetzt verfügbar. GKE On-Prem 1.3.4, jetzt verfügbar. Das Nutzen dieser Sicherheitslücke erfordert CAP_NET_RAW, aber nur sehr wenige Container erfordern normalerweise `CAP_NET_RAW`. Diese und andere leistungsstarke Funktionen sollten standardmäßig über `PodSecurityPolicy` oder den Policy Controller blockiert werden: Erzwingen Sie das Blockieren dieser Funktionen mit `PodSecurityPolicy`. Beispiel: # 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 Oder verwenden Sie Policy Controller oder Gatekeeper mit dieser Einschränkungsvorlage und wenden Sie sie an. Beispiel: # 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" Durch Aktualisieren der Pod-Spezifikationen: # 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 Welche Sicherheitslücke wird mit diesem Patch behoben? Der Patch entschärft die folgende Sicherheitslücke: Die Sicherheitslücke CVE-2020-14386, durch die Container mit CAP_NET_RAW 1 bis 10 Byte des Kernel-Speichers schreiben können und ein Container-Escape möglich wird, bei dem Container Root-Berechtigungen auf dem Hostknoten erhalten. Der Schweregrad dieser Sicherheitslücke ist "Hoch".	Hoch	CVE-2020-14386

Im Linux-Kernel wurde eine Sicherheitslücke entdeckt, die unter CVE-2020-14386 beschrieben ist. Damit kann Container-Escape Root-Berechtigungen für den Hostknoten erhalten.

Alle GKE On-Prem-Knoten sind betroffen.

Was soll ich tun?

Aktualisieren Sie Ihren Cluster auf eine Patchversion, um diese Sicherheitslücke zu schließen. Die folgenden geplanten GKE On-Prem-Versionen enthalten die Korrektur dieser Sicherheitslücke. Das Bulletin wird aktualisiert, sobald sie verfügbar sind:

GKE On-Prem 1.4.3, jetzt verfügbar.
GKE On-Prem 1.3.4, jetzt verfügbar.

Das Nutzen dieser Sicherheitslücke erfordert CAP_NET_RAW, aber nur sehr wenige Container erfordern normalerweise CAP_NET_RAW. Diese und andere leistungsstarke Funktionen sollten standardmäßig über PodSecurityPolicy oder den Policy Controller blockiert werden:

Erzwingen Sie das Blockieren dieser Funktionen mit PodSecurityPolicy. Beispiel:


      # 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

Oder verwenden Sie Policy Controller oder Gatekeeper mit dieser Einschränkungsvorlage und wenden Sie sie an. Beispiel:


      # 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"

Durch Aktualisieren der Pod-Spezifikationen:


      # 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

Welche Sicherheitslücke wird mit diesem Patch behoben?

Der Patch entschärft die folgende Sicherheitslücke:

Die Sicherheitslücke CVE-2020-14386, durch die Container mit CAP_NET_RAW
1 bis 10 Byte des Kernel-Speichers schreiben können und ein Container-Escape möglich wird, bei dem Container Root-Berechtigungen auf dem Hostknoten erhalten. Der Schweregrad dieser Sicherheitslücke ist "Hoch".

Hoch

CVE-2020-14386

GCP-2020-011

Veröffentlicht: 24.07.2020

Beschreibung	Schweregrad	Hinweise
Bei Kubernetes wurde vor Kurzem eine Sicherheitslücke im Netzwerk, CVE-2020-8558, entdeckt. Dienste kommunizieren manchmal über die lokale Loopback-Schnittstelle (127.0.0.1) mit anderen Anwendungen, die im gleichen Pod ausgeführt werden. Diese Sicherheitslücke ermöglicht einem Angreifer mit Zugriff auf das Netzwerk des Clusters, Traffic an die Loopback-Schnittstelle von angrenzenden Pods und Knoten zu senden. Dienste, die darauf angewiesen sind, dass die Loopback-Schnittstelle außerhalb ihres Pods nicht zugänglich ist, könnten ausgenutzt werden. Was soll ich tun? Aktualisieren Sie Ihren Cluster auf eine Patchversion, um diese Sicherheitslücke zu schließen. Die folgenden GKE-On-Prem-Versionen oder höher enthalten die Fehlerkorrektur für diese Sicherheitslücke: GKE On-Prem 1.4.1 Welche Sicherheitslücke wird mit diesem Patch behoben? Mit diesem Patch wird die folgende Sicherheitslücke behoben: CVE-2020-8558.	Mittel	CVE-2020-8558

Beschreibung

Schweregrad

Hinweise

Bei Kubernetes wurde vor Kurzem eine Sicherheitslücke im Netzwerk, CVE-2020-8558, entdeckt. Dienste kommunizieren manchmal über die lokale Loopback-Schnittstelle (127.0.0.1) mit anderen Anwendungen, die im gleichen Pod ausgeführt werden. Diese Sicherheitslücke ermöglicht einem Angreifer mit Zugriff auf das Netzwerk des Clusters, Traffic an die Loopback-Schnittstelle von angrenzenden Pods und Knoten zu senden. Dienste, die darauf angewiesen sind, dass die Loopback-Schnittstelle außerhalb ihres Pods nicht zugänglich ist, könnten ausgenutzt werden.

Was soll ich tun?

Aktualisieren Sie Ihren Cluster auf eine Patchversion, um diese Sicherheitslücke zu schließen. Die folgenden GKE-On-Prem-Versionen oder höher enthalten die Fehlerkorrektur für diese Sicherheitslücke:

GKE On-Prem 1.4.1

Welche Sicherheitslücke wird mit diesem Patch behoben?

Mit diesem Patch wird die folgende Sicherheitslücke behoben: CVE-2020-8558.

Mittel

CVE-2020-8558

GCP-2020-009

Veröffentlicht: 15.07.2020

Beschreibung	Schweregrad	Hinweise
Vor Kurzem wurde in Kubernetes eine Sicherheitslücke zur Rechteausweitung, CVE-2020-8559, entdeckt. Diese Sicherheitslücke ermöglicht es einem Angreifer, der bereits einen Knoten manipuliert hat, in jedem Pod im Cluster einen Befehl auszuführen. Der Angreifer kann dadurch mit dem bereits manipulierten Knoten andere Knoten manipulieren und potenziell Informationen lesen oder destruktive Aktionen ausführen. Damit ein Angreifer diese Sicherheitslücke ausnutzen kann, muss bereits ein Knoten im Cluster manipuliert worden sein. Diese Sicherheitslücke allein lässt also nicht die Manipulation von Knoten in Ihrem Cluster zu. Was soll ich tun? Aktualisieren Sie Ihr Cluster auf eine Patchversion. Die folgenden geplanten GKE On-Prem-Versionen oder höher enthalten die Fehlerkorrektur für diese Sicherheitslücke: Anthos 1.3.3 Anthos 1.4.1 Welche Sicherheitslücke wird mit diesem Patch behoben? Diese Patches beheben die Sicherheitslücke CVE-2020-8559. Diese Sicherheitslücke wird für GKE mit dem Schweregrad "Mittel" eingestuft, da der Angreifer Informationen aus erster Hand über den Cluster, die Knoten und Arbeitslasten benötigt, um diesen Angriff wirksam zu nutzen, und bereits ein anderer Knoten manipuliert worden sein muss. Diese Sicherheitslücke selbst bietet dem Angreifer keinen manipulierten Knoten.	Mittel	CVE-2020-8559

Beschreibung

Schweregrad

Hinweise

Vor Kurzem wurde in Kubernetes eine Sicherheitslücke zur Rechteausweitung, CVE-2020-8559, entdeckt. Diese Sicherheitslücke ermöglicht es einem Angreifer, der bereits einen Knoten manipuliert hat, in jedem Pod im Cluster einen Befehl auszuführen. Der Angreifer kann dadurch mit dem bereits manipulierten Knoten andere Knoten manipulieren und potenziell Informationen lesen oder destruktive Aktionen ausführen.

Damit ein Angreifer diese Sicherheitslücke ausnutzen kann, muss bereits ein Knoten im Cluster manipuliert worden sein. Diese Sicherheitslücke allein lässt also nicht die Manipulation von Knoten in Ihrem Cluster zu.

Was soll ich tun?

Aktualisieren Sie Ihr Cluster auf eine Patchversion. Die folgenden geplanten GKE On-Prem-Versionen oder höher enthalten die Fehlerkorrektur für diese Sicherheitslücke:

Anthos 1.3.3
Anthos 1.4.1

Welche Sicherheitslücke wird mit diesem Patch behoben?

Diese Patches beheben die Sicherheitslücke CVE-2020-8559. Diese Sicherheitslücke wird für GKE mit dem Schweregrad "Mittel" eingestuft, da der Angreifer Informationen aus erster Hand über den Cluster, die Knoten und Arbeitslasten benötigt, um diesen Angriff wirksam zu nutzen, und bereits ein anderer Knoten manipuliert worden sein muss. Diese Sicherheitslücke selbst bietet dem Angreifer keinen manipulierten Knoten.

Mittel

CVE-2020-8559

GCP-2020-007

Veröffentlicht: 01.06.2020

Beschreibung Schweregrad Hinweise

Beschreibung	Schweregrad	Hinweise
Serverseitige Anfragefälschung (Server Side Request Forgery, SSRF), CVE-2020-8555, wurde kürzlich in Kubernetes entdeckt und ermöglicht bestimmten autorisierten Nutzern, bis zu 500 Byte vertraulicher Informationen aus dem Hostnetzwerk der Steuerungsebene abzurufen. Die Google Kubernetes Engine-Steuerungsebene (GKE) verwendet Controller von Kubernetes und ist daher von dieser Sicherheitslücke betroffen. Wir empfehlen Ihnen, die Steuerungsebene wie unten beschrieben auf die neueste Patchversion zu aktualisieren. Ein Knotenupgrade ist nicht erforderlich. Was soll ich tun? Die folgenden geplanten GKE On-Prem-Versionen oder höher enthalten die Fehlerkorrektur für diese Sicherheitslücke: Anthos 1.3.0 Wenn Sie eine frühere Version verwenden, aktualisieren Sie Ihren vorhandenen Cluster auf eine Version, die diese Fehlerkorrektur enthält. Welche Sicherheitslücke wird mit diesem Patch behoben? Diese Patches beheben die Sicherheitslücke CVE-2020-8555. Diese Sicherheitslücke wird in GKE mit dem Schweregrad "Mittel" bewertet, da sie aufgrund verschiedener Härtungsmaßnahmen der Steuerungsebene nur schwer ausgenutzt werden konnte. Ein Angreifer mit Berechtigungen zum Erstellen eines Pods mit bestimmten integrierten Volume-Typen (GlusterFS, Quobyte, StorageFS, ScaleIO) oder Berechtigungen zum Erstellen einer StorageClass kann `kube-controller-manager` dazu veranlassen, `GET`-Anfragen oder `POST`-Anfragen ohne von ihm kontrolliertem Anfragetext über das Master-Hostnetzwerk zu senden. Diese Volume-Typen werden selten auf GKE verwendet. Neue Nutzungsfälle dieser Volume-Typen können also ein hilfreiches Signal zur Angriffserkennung sein. Wird der Angriff mit einer Methode kombiniert, um die Ergebnisse von `GET/POST` beispielsweise durch Logs zurück an den Angreifer zu senden, kann das zur Offenlegung von vertraulichen Informationen führen. Wir haben die entsprechenden Speichertreiber aktualisiert, um das Risiko von Schwachstellen zu beheben.	Mittel	CVE-2020-8555

Serverseitige Anfragefälschung (Server Side Request Forgery, SSRF), CVE-2020-8555, wurde kürzlich in Kubernetes entdeckt und ermöglicht bestimmten autorisierten Nutzern, bis zu 500 Byte vertraulicher Informationen aus dem Hostnetzwerk der Steuerungsebene abzurufen. Die Google Kubernetes Engine-Steuerungsebene (GKE) verwendet Controller von Kubernetes und ist daher von dieser Sicherheitslücke betroffen. Wir empfehlen Ihnen, die Steuerungsebene wie unten beschrieben auf die neueste Patchversion zu aktualisieren. Ein Knotenupgrade ist nicht erforderlich.

Was soll ich tun?

Die folgenden geplanten GKE On-Prem-Versionen oder höher enthalten die Fehlerkorrektur für diese Sicherheitslücke:

Anthos 1.3.0

Wenn Sie eine frühere Version verwenden, aktualisieren Sie Ihren vorhandenen Cluster auf eine Version, die diese Fehlerkorrektur enthält.

Welche Sicherheitslücke wird mit diesem Patch behoben?

Diese Patches beheben die Sicherheitslücke CVE-2020-8555. Diese Sicherheitslücke wird in GKE mit dem Schweregrad "Mittel" bewertet, da sie aufgrund verschiedener Härtungsmaßnahmen der Steuerungsebene nur schwer ausgenutzt werden konnte.

Ein Angreifer mit Berechtigungen zum Erstellen eines Pods mit bestimmten integrierten Volume-Typen (GlusterFS, Quobyte, StorageFS, ScaleIO) oder Berechtigungen zum Erstellen einer StorageClass kann kube-controller-manager dazu veranlassen, GET-Anfragen oder POST-Anfragen ohne von ihm kontrolliertem Anfragetext über das Master-Hostnetzwerk zu senden. Diese Volume-Typen werden selten auf GKE verwendet. Neue Nutzungsfälle dieser Volume-Typen können also ein hilfreiches Signal zur Angriffserkennung sein.

Wird der Angriff mit einer Methode kombiniert, um die Ergebnisse von GET/POST beispielsweise durch Logs zurück an den Angreifer zu senden, kann das zur Offenlegung von vertraulichen Informationen führen. Wir haben die entsprechenden Speichertreiber aktualisiert, um das Risiko von Schwachstellen zu beheben.

Mittel

CVE-2020-8555

GCP-2020-006

Veröffentlicht: 01.06.2020

Beschreibung Schweregrad Hinweise

Beschreibung	Schweregrad	Hinweise
Kubernetes hat eine Sicherheitslücke entdeckt, die es einem berechtigten Container ermöglicht, Knoten-Traffic an einen anderen Container weiterzuleiten. Gegenseitiger TLS/SSH-Traffic, z. B. zwischen dem Kubelet und dem API-Server oder Traffic von Anwendungen, die mTLS verwenden, kann durch diesen Angriff nicht gelesen oder geändert werden. Alle GKE-Knoten (Google Kubernetes Engine) sind von dieser Sicherheitslücke betroffen. Wir empfehlen Ihnen, ein Upgrade auf die neueste Patchversion auszuführen. Was soll ich tun? Führen Sie ein Upgrade Ihrer Cluster auf die folgende Version oder höher aus, um diese Sicherheitslücke für GKE On-Prem zu verringern: Anthos 1.3.2 Normalerweise benötigen nur sehr wenige Container `CAP_NET_RAW`. Diese und andere leistungsstarke Funktionen sollten standardmäßig über Anthos Policy Controller oder durch Aktualisieren Ihrer Pod-Spezifikationen blockiert werden: So entfernen Sie die `CAP_NET_RAW`-Funktion aus Containern: Durch Verwendung von Anthos Policy Controller/Gatekeeper mit dieser Einschränkungsvorlage und Anwendung der Vorlage. Beispiel: # 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" Durch Aktualisieren der Pod-Spezifikationen: # Dropping CAP_NET_RAW from a Pod: apiVersion: v1 kind: Pod metadata: name: no-cap-net-raw spec: containers: -name: m4028y-container ... securityContext: capabilities: drop: -NET_RAW Welche Sicherheitslücke wird mit diesem Patch behoben? Dieser Patch dient zur Entschärfung der folgenden Sicherheitslücke: Die Sicherheitslücke, die unter Kubernetes-Problem 91507 beschrieben ist. Dabei kann die `CAP_NET_RAW`-Funktion (im standardmäßigen Container-Funktionsset enthalten) den IPv6-Stack auf dem Knoten schädlich konfigurieren und den Knoten-Traffic an den vom Angreifer kontrollierten Container weiterleiten. Dadurch kann der Angreifer ausgehenden und eingehenden Traffic des Knotens abfangen und ändern. Gegenseitiger TLS/SSH-Traffic, z. B. zwischen dem Kubelet und dem API-Server oder Traffic von Anwendungen, die mTLS verwenden, kann durch diesen Angriff nicht gelesen oder geändert werden.	Mittel	Kubernetes-Problem 91507

Kubernetes hat eine Sicherheitslücke entdeckt, die es einem berechtigten Container ermöglicht, Knoten-Traffic an einen anderen Container weiterzuleiten. Gegenseitiger TLS/SSH-Traffic, z. B. zwischen dem Kubelet und dem API-Server oder Traffic von Anwendungen, die mTLS verwenden, kann durch diesen Angriff nicht gelesen oder geändert werden. Alle GKE-Knoten (Google Kubernetes Engine) sind von dieser Sicherheitslücke betroffen. Wir empfehlen Ihnen, ein Upgrade auf die neueste Patchversion auszuführen.

Was soll ich tun?

Führen Sie ein Upgrade Ihrer Cluster auf die folgende Version oder höher aus, um diese Sicherheitslücke für GKE On-Prem zu verringern:

Anthos 1.3.2

Normalerweise benötigen nur sehr wenige Container CAP_NET_RAW. Diese und andere leistungsstarke Funktionen sollten standardmäßig über Anthos Policy Controller oder durch Aktualisieren Ihrer Pod-Spezifikationen blockiert werden:

So entfernen Sie die CAP_NET_RAW-Funktion aus Containern:

Durch Verwendung von Anthos Policy Controller/Gatekeeper mit dieser Einschränkungsvorlage und Anwendung der Vorlage. Beispiel:


# 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"

Durch Aktualisieren der Pod-Spezifikationen:


# Dropping CAP_NET_RAW from a Pod:
apiVersion: v1
kind: Pod
metadata:
  name: no-cap-net-raw
spec:
  containers:
    -name: m4028y-container
     ...
    securityContext:
      capabilities:
        drop:
          -NET_RAW

Welche Sicherheitslücke wird mit diesem Patch behoben?

Dieser Patch dient zur Entschärfung der folgenden Sicherheitslücke:

Die Sicherheitslücke, die unter Kubernetes-Problem 91507 beschrieben ist. Dabei kann die CAP_NET_RAW-Funktion (im standardmäßigen Container-Funktionsset enthalten) den IPv6-Stack auf dem Knoten schädlich konfigurieren und den Knoten-Traffic an den vom Angreifer kontrollierten Container weiterleiten. Dadurch kann der Angreifer ausgehenden und eingehenden Traffic des Knotens abfangen und ändern. Gegenseitiger TLS/SSH-Traffic, z. B. zwischen dem Kubelet und dem API-Server oder Traffic von Anwendungen, die mTLS verwenden, kann durch diesen Angriff nicht gelesen oder geändert werden.

Mittel

Kubernetes-Problem 91507

GCP-2020-004

Beschreibung	Schweregrad	Hinweise
In Kubernetes wurde kürzlich eine in CVE-2019-11254 beschriebene Sicherheitslücke festgestellt. Sie erlaubt Nutzern, die POST-Anfragen stellen dürfen, DoS-Remoteangriffe auf Kubernetes API-Server. Das Kubernetes Product Security Committee (PSC) hat zusätzliche Informationen zu dieser Sicherheitslücke veröffentlicht. Sie können diese Sicherheitslücke minimieren, indem Sie beschränken, welche Clients Netzwerkzugriff auf Ihre Kubernetes API-Server haben. Was soll ich tun? Wir empfehlen Ihnen, Ihre Cluster so bald wie möglich auf eine Patchversion zu aktualisieren, die diese Fehlerkorrektur enthält. Die Patchversionen, mit denen die Sicherheitslücke behoben wird, sind unten aufgeführt: Anthos 1.3.0, auf dem die Kubernetes-Version 1.15.7-gke.32 ausgeführt wird Welche Sicherheitslücken werden mit diesem Patch behoben? Mit dem Patch wird die folgende DoS-Sicherheitslücke (Denial of Service) behoben: CVE-2019-11254	Mittel	CVE-2019-11254

Beschreibung

Schweregrad

Hinweise

In Kubernetes wurde kürzlich eine in CVE-2019-11254 beschriebene Sicherheitslücke festgestellt. Sie erlaubt Nutzern, die POST-Anfragen stellen dürfen, DoS-Remoteangriffe auf Kubernetes API-Server. Das Kubernetes Product Security Committee (PSC) hat zusätzliche Informationen zu dieser Sicherheitslücke veröffentlicht.

Sie können diese Sicherheitslücke minimieren, indem Sie beschränken, welche Clients Netzwerkzugriff auf Ihre Kubernetes API-Server haben.

Was soll ich tun?

Wir empfehlen Ihnen, Ihre Cluster so bald wie möglich auf eine Patchversion zu aktualisieren, die diese Fehlerkorrektur enthält.

Die Patchversionen, mit denen die Sicherheitslücke behoben wird, sind unten aufgeführt:

Anthos 1.3.0, auf dem die Kubernetes-Version 1.15.7-gke.32 ausgeführt wird

Welche Sicherheitslücken werden mit diesem Patch behoben?

Mit dem Patch wird die folgende DoS-Sicherheitslücke (Denial of Service) behoben:

CVE-2019-11254

Mittel

CVE-2019-11254

16. Oktober 2019

Beschreibung	Schweregrad	Hinweise
In Kubernetes wurde kürzlich eine in CVE-2019-11253 beschriebene Sicherheitslücke festgestellt. Sie erlaubt Nutzern, die POST-Anfragen stellen dürfen, die externe Ausführung von DoS-Angriffen (Denial of Service) auf Kubernetes API-Server. Das Kubernetes Product Security Committee (PSC) hat zusätzliche Informationen zu dieser Sicherheitslücke veröffentlicht. Sie können diese Sicherheitslücke minimieren, indem Sie beschränken, welche Clients Netzwerkzugriff auf Ihre Kubernetes API-Server haben. Was soll ich tun? Wir empfehlen, so bald wie möglich ein Upgrade Ihrer Cluster auf eine Patchversion auszuführen, die eine entsprechende Fehlerkorrektur enthält. Die Patchversionen mit dieser Fehlerkorrektur sind unten aufgeführt: Anthos 1.1.1, auf dem die Kubernetes-Version 1.13.7-gke.30 ausgeführt wird Welche Sicherheitslücke wird mit diesem Patch behoben? Der Patch entschärft die Sicherheitslücke CVE-2019-11253.	Hoch	CVE-2019-11253

Beschreibung

Schweregrad

Hinweise

In Kubernetes wurde kürzlich eine in CVE-2019-11253 beschriebene Sicherheitslücke festgestellt. Sie erlaubt Nutzern, die POST-Anfragen stellen dürfen, die externe Ausführung von DoS-Angriffen (Denial of Service) auf Kubernetes API-Server. Das Kubernetes Product Security Committee (PSC) hat zusätzliche Informationen zu dieser Sicherheitslücke veröffentlicht.

Sie können diese Sicherheitslücke minimieren, indem Sie beschränken, welche Clients Netzwerkzugriff auf Ihre Kubernetes API-Server haben.

Was soll ich tun?

Wir empfehlen, so bald wie möglich ein Upgrade Ihrer Cluster auf eine Patchversion auszuführen, die eine entsprechende Fehlerkorrektur enthält.

Die Patchversionen mit dieser Fehlerkorrektur sind unten aufgeführt:

Anthos 1.1.1, auf dem die Kubernetes-Version 1.13.7-gke.30 ausgeführt wird

Welche Sicherheitslücke wird mit diesem Patch behoben?

Der Patch entschärft die Sicherheitslücke CVE-2019-11253.

Hoch

CVE-2019-11253

23. August 2019

Beschreibung Schweregrad Hinweise

Beschreibung	Schweregrad	Hinweise
Wir haben vor Kurzem eine Sicherheitslücke entdeckt und beseitigt, durch die der für Sicherheitsmonitoring-Endpunkte verwendete RBAC-Proxy die Nutzer nicht richtig autorisierte. Daher waren Messwerte aus bestimmten Komponenten für nicht autorisierte Nutzer innerhalb des internen Clusternetzwerks verfügbar. Die folgenden Komponenten waren betroffen: `etcd` `etcd-events` `kube-apiserver` `kube-controller-manager` `kube-scheduler` `node-exporter` `kube-state-metrics` `prometheus` `alertmanager` Was soll ich tun? Wir empfehlen Ihnen, so schnell wie möglich ein Upgrade Ihrer Cluster auf Version 1.0.2-gke.3 auszuführen, die den Patch für diese Sicherheitslücke enthält.	Mittel	GKE On-Prem-Releases

Wir haben vor Kurzem eine Sicherheitslücke entdeckt und beseitigt, durch die der für Sicherheitsmonitoring-Endpunkte verwendete RBAC-Proxy die Nutzer nicht richtig autorisierte. Daher waren Messwerte aus bestimmten Komponenten für nicht autorisierte Nutzer innerhalb des internen Clusternetzwerks verfügbar. Die folgenden Komponenten waren betroffen:

etcd
etcd-events
kube-apiserver
kube-controller-manager
kube-scheduler
node-exporter
kube-state-metrics
prometheus
alertmanager

Was soll ich tun?

Wir empfehlen Ihnen, so schnell wie möglich ein Upgrade Ihrer Cluster auf Version 1.0.2-gke.3 auszuführen, die den Patch für diese Sicherheitslücke enthält.

Mittel

GKE On-Prem-Releases

22. August 2019

Beschreibung	Schweregrad	Hinweise
Kubernetes hat kürzlich die Sicherheitslücke CVE-2019-11247 festgestellt. Dadurch können clusterbezogene benutzerdefinierte Ressourceninstanzen wie mit einem Namespace versehene Objekte behandelt werden, die in allen Namespaces existieren. Das bedeutet, dass Nutzer und Dienstkonten, die lediglich RBAC-Berechtigungen auf Namespace-Ebene haben, mit clusterbezogenen benutzerdefinierten Ressourcen interagieren können. Damit der Angreifer diese Sicherheitslücke nutzen kann, benötigt er Zugriffsrechte auf die Ressource in einem Namespace. Was soll ich tun? Wir empfehlen Ihnen, so schnell wie möglich ein Upgrade Ihrer Cluster auf Version 1.0.2-gke.3 auszuführen, die den Patch für diese Sicherheitslücke enthält. Welche Sicherheitslücke wird mit diesem Patch behoben? Der Patch entschärft die Sicherheitslücke CVE-2019-11247.	Mittel	CVE-2019-11247

Beschreibung

Schweregrad

Hinweise

Kubernetes hat kürzlich die Sicherheitslücke CVE-2019-11247 festgestellt. Dadurch können clusterbezogene benutzerdefinierte Ressourceninstanzen wie mit einem Namespace versehene Objekte behandelt werden, die in allen Namespaces existieren. Das bedeutet, dass Nutzer und Dienstkonten, die lediglich RBAC-Berechtigungen auf Namespace-Ebene haben, mit clusterbezogenen benutzerdefinierten Ressourcen interagieren können. Damit der Angreifer diese Sicherheitslücke nutzen kann, benötigt er Zugriffsrechte auf die Ressource in einem Namespace.

Was soll ich tun?

Wir empfehlen Ihnen, so schnell wie möglich ein Upgrade Ihrer Cluster auf Version 1.0.2-gke.3 auszuführen, die den Patch für diese Sicherheitslücke enthält.

Welche Sicherheitslücke wird mit diesem Patch behoben?

Der Patch entschärft die Sicherheitslücke CVE-2019-11247.

Mittel

CVE-2019-11247