Sicherheitspatches

In diesem Dokument wird beschrieben, wie Google Sicherheitslücken und Patches für Google Kubernetes Engine (GKE) verwaltet. Diese Informationen sind möglicherweise für Sicherheitsexperten nützlich, die bei der Behebung von Sicherheitsproblemen oder Sicherheitslücken unterstützen, für die strategische Unterstützung erforderlich ist, z. B. Vorfälle und Probleme, die vom Support eskaliert wurden.

Gemeinsame Verantwortung für Patches

Das Patchen ist eine gemeinsame Verantwortung von Google und dem Kunden. Verschiedene Plattformen haben unterschiedliche geteilte Verantwortlichkeiten. Weitere Informationen zu den einzelnen Plattformen finden Sie unter:

So erkennen wir Sicherheitslücken

Google hat große Investitionen in proaktives Sicherheitsdesign und Härtung durchgeführt. Doch selbst die besten Softwaresysteme können Sicherheitslücken haben. Um diese Sicherheitslücken zu finden und zu patchen, bevor sie ausgenutzt werden können, hat Google erhebliche in mehrere Bereiche investiert.

Zu Patchzwecken ist GKE eine Betriebssystemebene, auf der Container ausgeführt werden. Die Betriebssysteme, Container-Optimized OS oder Ubuntu, sind gehärtet und enthalten die Software, die mindestens für die Ausführung von Containern erforderlich ist. GKE-Features werden als Container auf den Basis-Images ausgeführt. GKE arbeitet kontinuierlich daran, die Anzahl der Abhängigkeiten von Systemkomponenten zu reduzieren. Dies trägt dazu bei, die Angriffsfläche zu verringern und die Effizienz der Verwaltung von Sicherheitslücken zu verbessern. Beispielsweise verwenden GKE-Systemkomponenten nach Möglichkeit minimale Basis-Images.

Google erkennt und behebt Sicherheitslücken und fehlende Patches auf folgende Weise:

  • Container-Optimized OS: Google scannt Images, um potenzielle Sicherheitslücken und fehlende Patches zu ermitteln. Das Team für Container-Optimized OS prüft und behebt Probleme.

  • Ubuntu: Canonical stellt Google Betriebssystem-Builds zur Verfügung, auf denen alle verfügbaren Sicherheitspatches angewendet sind.

Google scannt Container mit Container Registry-Artefaktanalyse, um Sicherheitslücken und fehlende Patches in Kubernetes- und von Google verwalteten Containern zu ermitteln. Wenn Fehlerkorrekturen verfügbar sind, startet der Scanner automatisch den Patch- und Releaseprozess.

Zusätzlich zu automatisierten Scans erkennt Google Sicherheitslücken, die Scannern unbekannt sind, und behebt sie so:

Google führt Audits, Penetrationstests und Sicherheitslückenerkennung auf allen Plattformen durch. Eine Liste der Plattformen finden Sie im vorherigen Abschnitt Gemeinsame Verantwortung für Patches.

Spezialisierte Teams innerhalb von Google und vertrauenswürdigen Drittanbietern von Sicherheitslösungen führen eigene Angriffsuntersuchungen durch. Google arbeitet auch mit der CNCF zusammen, um einen großen Teil der Organisation und des technischen Fachwissens für das Kubernetes-Sicherheits-Audit bereitzustellen.

Google interagiert aktiv über mehrere Prämienprogramme zu Sicherheitslücken mit der Sicherheitsforschungs-Community. Ein dediziertes Google Cloud Programm zu Sicherheitslücken bietet erhebliche Vorteile, unter anderem 133.337 $ für die bedeutendste Cloud-Sicherheitslücke des Jahres. Für GKE gibt es ein Programm, das Sicherheitsforscher belohnt, wenn sie unsere Sicherheitsvorkehrungen überwinden können. Das Programm deckt alle GKE-Softwareabhängigkeiten ab.

Google arbeitet mit anderen Branchen- und Open-Source-Softwarepartnern zusammen, die Sicherheitslücken, Sicherheitsforschung und Patches vor der Veröffentlichung der Sicherheitslücke teilen. Das Ziel dieser Zusammenarbeit besteht darin, große Teile der Internetinfrastruktur zu patchen, bevor die Sicherheitslücke öffentlich bekannt gegeben wird. In manchen Fällen informiert Google diese Community über Sicherheitslücken. Beispielsweise hat Project Zero von Google die Sicherheitslücken Spectre und Meltdown entdeckt und veröffentlicht. Das Google Cloud Sicherheitsteam sucht und behebt auch Sicherheitslücken in der Kernel-basierte virtuelle Maschine (KVM).

Die Sicherheitszusammenarbeit von Google findet auf vielen Ebenen statt. Gelegentlich geschieht dies über Programme, bei denen Organisationen sich anmelden, um Vorabbenachrichtigungen über Software-Sicherheitslücken für Produkte wie Kubernetes und Envoy zu empfangen. Die Zusammenarbeit erfolgt auch informell durch unsere Beteiligung an vielen Open-Source-Projekten wie dem Linux-Kernel, den Containerlaufzeiten, der Virtualisierungstechnologie und anderen.

Für Kubernetes ist Google ein aktives Gründungsmitglied des Security Response Committee (SRC), das einen Großteil des Sicherheitsrelease-Prozesses geschrieben hat. Google ist Mitglied der Liste der Kubernetes-Vertriebspartner , die im Voraus Benachrichtigungen zu Sicherheitslücken erhalten, und war an der Prüfung, dem Patchen, den Maßnahmen zur Risikominderung und der Kommunikation bei nahezu allen schwere Kubernetes-Sicherheitslücken beteiligt. Google hat auch mehrere Kubernetes-Sicherheitslücken entdeckt, z. B. CVE-2019-11254, CVE-2019-11255 und CVE-2021-25741.

Außerhalb dieser Prozesse werden weniger schwerwiegende Sicherheitslücken erkannt und gepatcht. Die meisten Sicherheitslücken werden über einen der zuvor aufgeführten Kanäle privat gemeldet. Die frühzeitige Berichterstattung gibt Google genügend Zeit, bevor die Sicherheitslücke veröffentlicht wird, zu erfahren, wie sie sich auf GKE auswirkt, Patches oder Abhilfemaßnahmen zu entwickeln und Beratung und Kommunikation für Kunden vorzubereiten. Wenn möglich, patcht Google alle Cluster vor der Veröffentlichung der Sicherheitslücke.

Klassifizierung von Sicherheitslücken

GKE investiert viel in die Sicherheit des gesamten Stacks ein, einschließlich Betriebssystem-, Container-, Kubernetes- und Netzwerkebenen, zusätzlich zum Festlegen geeigneter Standardeinstellungen, sicherheitsoptimierter Konfigurationen und verwalteter Komponenten. In Kombination werden diese Anstrengungen dazu beitragen, die Auswirkungen und die Wahrscheinlichkeit von Sicherheitslücken zu reduzieren.

Das GKE-Sicherheitsteam klassifiziert Sicherheitslücken gemäß dem Kubernetes-System zur Sicherheitslückenbewertung. Bei Klassifizierungen werden viele Faktoren berücksichtigt, unter anderem die GKE-Konfiguration sowie die Härtung der Sicherheit. Aufgrund dieser Faktoren und der Investitionen, die GKE in die Sicherheit tätigt, können sich die Klassifizierungen von GKE von anderen Klassifizierungsquellen unterscheiden.

In der folgenden Tabelle werden die Schweregrade von Sicherheitslücken beschrieben:

Schweregrad Beschreibung
Kritisch Eine Sicherheitslücke, die in allen Clustern leicht ausnutzbar ist durch einen nicht authentifizierten Remote-Angreifer, der zu einem vollständigen Systemmissbrauch führt.
Hoch Eine Sicherheitslücke, die für viele Cluster ausgenutzt werden kann, was zum Verlust von Vertraulichkeit, Integrität oder Verfügbarkeit führt.
Mittel Eine Sicherheitslücke, die für einige Cluster genutzt werden kann, bei denen der Verlust von Vertraulichkeit, Integrität oder Verfügbarkeit durch allgemeine Konfigurationen, der Schwere des Exploits, den erforderlichen Zugriff oder die Nutzerinteraktion beeinträchtigt wird.
Niedrig Alle anderen Sicherheitslücken. Die Ausnutzung ist unwahrscheinlich oder die Konsequenzen der Ausnutzung sind begrenzt.

In den Sicherheitsbulletins finden Sie Beispiele für Sicherheitslücken, Fehlerbehebungen und Risikominderungen sowie deren Bewertungen.

Sicherheitslücken für GKE-Cluster patchen

Beim Patchen einer Sicherheitslücke muss ein Upgrade auf eine neue GKE-Versionsnummer durchgeführt werden. GKE-Versionen enthalten versionierte Komponenten für das Betriebssystem, Kubernetes-Komponenten und andere Container, aus denen die GKE-Plattform besteht. Das Beheben einiger Sicherheitslücken erfordert nur ein Upgrade der Steuerungsebene, das automatisch von Google in GKE durchgeführt wird, während für andere sowohl Steuerungsebenen- als auch Knotenupgrades erforderlich sind.

Damit Cluster immer gepatcht und vor Sicherheitslücken geschützt bleiben, empfehlen wir die Verwendung von automatischem Knotenupgrade in GKE (standardmäßig aktiviert). Bei Clustern, die für Release-Versionen registriert sind, werden Patch-Releases hochgestuft, wenn sie die Qualifikationsanforderungen der jeweiligen Kanäle erfüllen. Wenn Sie einen GKE-Patch-Release benötigen, bevor er den Releasekanal Ihres Clusters erreicht, können Sie ein manuelles Upgrade auf die Patch-Version ausführen, falls die Patch-Version des Release auf der gleichen Nebenversion wie der im Releasekanal Ihres Clusters verfügbaren Nebenversion basiert.

Auf anderen Plattformen, auf denen Cluster ausgeführt werden, empfiehlt Google, mindestens einmal pro Monat ein Upgrade durchzuführen. Eine Liste der Plattformen finden Sie im vorherigen Abschnitt Gemeinsame Verantwortung für Patches.

Einige Sicherheitsscanner oder manuelle Versionsüberprüfungen gehen möglicherweise fälschlicherweise davon aus, dass für eine Komponente wie runc oder containerd ein bestimmter Upstream-Sicherheits-Patch fehlt. In GKE werden Komponenten regelmäßig gepatcht und nur bei Bedarf Paketversionen aktualisiert. Das bedeutet, dass GKE-Komponenten funktional mit ihren Upstream-Entsprechungen vergleichbar sind, auch wenn die Versionsnummer der GKE-Komponente nicht mit der Upstream-Versionsnummer übereinstimmt. Details zu einer bestimmten CVE finden Sie in den GKE-Sicherheitsbulletins.

Zeitpläne für Patches

Das Ziel von Google ist es, erkannte Sicherheitslücken innerhalb eines Zeitraums zu minimieren, der für damit verbundene Risiken angemessen ist. GKE ist in der vorläufigen FedRAMP ATO von Google Cloud enthalten. Dies erfordert, dass bekannte Sicherheitslücken innerhalb bestimmter Zeiträume entsprechend ihres Schweregrades behoben werden, wie unter RA-5(d) in der Tabelle „Summary of Continuous Monitoring Activities & Deliverables“ (Zusammenfassung der Aktivitäten und Ergebnisse des kontinuierlichen Monitorings) im Leitfaden zur FedRAMP-Strategie für kontinuierliches Monitoring angegeben.Google Cloud

Für jede bekannte Sicherheitslücke ist es das Ziel von GKE, Patchversionen zu veröffentlichen, die die Sicherheitslücke innerhalb des entsprechenden Zeitraums beheben. Die Google Cloud vorläufige FedRAMP ATO umfasst Google Distributed Cloud, GKE on AWS, GKE on Azure und angehängte GKE-Cluster nicht. Wir bemühen uns jedoch, dieselben Zeiträume für Problembehebungen bei diesen Produkten zu erreichen. Nachdem GKE Patchversionen zur Behebung einer bekannten Sicherheitslücke zur Verfügung gestellt hat, aktualisieren Sie Ihre Cluster auf diese Versionen, um die Zeiträume für das Patchen für Ihre Organisation einzuhalten.

So wird über Sicherheitslücken und Patches informiert

Die beste Quelle für aktuelle Informationen zu Sicherheitslücken und Sicherheitspatches finden Sie in den Sicherheitsbulletin-Feeds der folgenden Produkte:

  • Google Kubernetes Engine (GKE)
  • Google Distributed Cloud (nur Software) auf VMware
  • GKE on AWS
  • GKE on Azure
  • Google Distributed Cloud (nur Software) auf Bare Metal

Diese Bulletins folgen einem gängigen Google Cloud Schema zur Sicherheitslückennummer und sind über die Hauptseite Google Cloud der Bulletins und die GKE-Versionshinweise verknüpft. Jede Sicherheitsbulletin-Seite verfügt über einen RSS-Feed, über den Nutzer Updates abonnieren können.

Sicherheitslücken werden manchmal für einen begrenzten Zeitraum privat gehalten und mit einem "Embargo" belegt. Embargos unterstützen bei der Verhinderung der frühzeitige Veröffentlichung von Sicherheitslücken, die zu ausgedehnte Angriffen führen können, bevor gegensteuernde Maßnahmen ergriffen werden können. In Embargo-Fällen sprechen die Versionshinweise von "Sicherheitsupdates", bis die Embargo aufgehoben wurde. Nachdem die Embargo aufgehoben wurde, aktualisiert Google Versionshinweise, um die jeweiligen Sicherheitslücken aufzunehmen

Das Sicherheitsteam von GKE Enterprise veröffentlicht Sicherheitsbulletins für Sicherheitslücken mit hohem und kritischem Schweregrad. Wenn Kunden Maßnahmen ergreifen müssen, um diese hohen und kritischen Sicherheitslücken zu adressieren, kontaktiert Google Kunden per E-Mail. Darüber hinaus kann Google Kunden mit Supportverträgen auch über Supportkanäle kontaktieren.

Wie kann ich einen Sicherheitspatch am schnellsten installieren?

Alle Cluster bleiben mit automatischen GKE-Upgrades automatisch gepatcht. In diesem Abschnitt wird beschrieben, wie Sie schneller als mit automatischen Upgrades bestimmte Sicherheitskorrekturen patchen oder dies fortlaufend tun. Durch die Kombination von Testumgebungen, manuellen kanalübergreifenden Upgrades, beschleunigten Patcheinstellungen und ereignisgesteuerten Benachrichtigungen können Sie die Vorlaufzeiten für das Patchen verkürzen.

GKE verwaltet die Einführung von Versionen in allen Release-Versionen, um sicherzustellen, dass neue Versionen qualifiziert und getestet werden. Um die Vorlaufzeiten für das Patchen zu verkürzen, müssen Sie verstehen, wie diese Rollouts funktionieren, und dann das Standardverhalten an Ihre spezifischen Anforderungen anpassen.

Beim Testen einer gepatchten Version wird sie über einen bestimmten Zeitraum auf Clustern ausgeführt, um die Stabilität zu beobachten. Dieser Prozess hilft, Fehler zu finden, die erst nach längerer Verwendung in verschiedenen Umgebungen auftreten. Um eine ausreichende Übergangszeit zu gewährleisten, werden GKE-Patch-Releases zuerst im Rapid Channel, dann im Regular Channel und schließlich im Stable Channel eingeführt. Releases werden auch in jedem Kanal getestet, bevor sie zum Standard-Upgradeziel für den Kanal werden.

Patches frühzeitig mit einem dedizierten Cluster im Rapid Channel qualifizieren

Um einen Sicherheitspatch zu qualifizieren, den Sie beschleunigen möchten, führen Sie einen dedizierten Cluster aus, der im Rapid Channel registriert ist und für den beschleunigte automatische Patch-Upgrades aktiviert sind. Verwenden Sie diesen Cluster, um die Kompatibilität der Arbeitslasten zu prüfen und Probleme zu erkennen, sobald eine Sicherheitskorrektur von Google veröffentlicht wird. Dieser Cluster kann als einmalige Qualifizierung für einen bestimmten Patch verwendet werden. Wenn er jedoch kontinuierlich ausgeführt wird, bietet er zusätzliche Zuverlässigkeitsvorteile für Ihre Flotte.

Testverzögerungen mit beschleunigten automatischen Patch-Upgrades reduzieren

Sobald Ihr im Rapid Channel registrierter Cluster eingerichtet ist, um Probleme zu erkennen, können Sie Patches schneller in Ihren Produktionsclustern im Regular Channel und Stable Channel verwenden. Aktivieren Sie beschleunigte automatische Patch-Upgrades für Ihre Produktionscluster, um Upgrades auf den neuesten Patch-Release in Ihrem registrierten Kanal durchzuführen, sobald er verfügbar ist. Mit dieser Funktion wird GKE angewiesen, die Übergangszeit im Kanal für Patch-Updates, insbesondere Sicherheitspatches, zu umgehen.

Manuelle Upgrades auf neuere Patchversionen im Regular Channel und Stable Channel

Wenn Ihre Produktionsarbeitslasten auf Clustern ausgeführt werden, die im Regular Channel oder Stable Channel registriert sind, müssen Sie diese Kanäle nicht verlassen oder warten, bis der automatische, schrittweise Rollout eines Patches Sie erreicht, wenn ein bestimmtes Sicherheitsupdate priorisiert werden muss.

Wenn Ihr im Rapid Channel registrierter Cluster einen Patch erfolgreich qualifiziert hat, können Sie manuell ein Upgrade auf Ihren Produktionsclustern im Regular Channel oder Stable Channel auf genau diese Patchversion initiieren.

Patchverwaltung mit ereignisgesteuerten Pub/Sub-Benachrichtigungen automatisieren

Sie müssen die Webseite mit den Sicherheitsbulletins nicht auf Patchinformationen prüfen. So erhalten Sie schnelle programmatische Benachrichtigungen über verfügbare Patches mit Pub/Sub, um die Patchqualifizierung und Upgradeaktionen auszulösen:

  • Ereignisgesteuerte Benachrichtigungen: Richten Sie Cluster Benachrichtigungen mit Pub/Sub ein.
  • Sicherheitsfilterung: Konfigurieren Sie Ihre Clusterbenachrichtigungen so, dass sie speziell nach SecurityBulletinEvent und UpgradeEventgefiltert werden.
  • Programmatische Aktion:GKE sendet programmatische Echtzeitnachrichten an Ihr Pub/Sub-Thema, wenn ein Sicherheitsbulletin veröffentlicht wird oder ein Patch, der ein Bulletin minimiert, für Ihren Cluster in Ihrer Zone oder Region verfügbar ist. Diese Benachrichtigungen können in Ihre SIEM-Systeme (Security Information and Event Management), Chatvorgänge eingebunden oder automatische Testpipelines auslösen.