Google-Verbindungen zur GKE-Steuerungsebene prüfen

Auf dieser Seite wird beschrieben, wie Sie Verbindungen von Google-Mitarbeitern zur Steuerungsebene Ihres Google Kubernetes Engine-Clusters (GKE) überprüfen können, indem Sie GKE-Logs mit Access Transparency-Logs korrelieren.

In Access Transparency-Logs werden die Aktionen aufgezeichnet, die Google-Mitarbeiter beim Zugriff auf Ihre Inhalte ausführen. Dieser Leitfaden richtet sich an Sicherheitsadministratoren, die die Inhalte von Access Transparency-Logs und die zugehörigen Access Approval-Genehmigungen zusätzlich überprüfen möchten, indem sie sie mit zusätzlichen Logging-Quellen aus GKE korrelieren. Diese Überprüfung ist völlig optional und nicht erforderlich, um Ihre Steuerungsebene zu schützen.

Machen Sie sich mit den folgenden Konzepten vertraut:

Auf dieser Seite wird ein Teil einer Reihe optionaler Features der Steuerungsebene in GKE beschrieben, mit denen Sie Aufgaben wie das Überprüfen der Sicherheitslage Ihrer Steuerungsebene oder das Konfigurieren der Verschlüsselung und der Anmeldedaten-Signierung auf der Steuerungsebene mit von Ihnen verwalteten Schlüsseln ausführen können. Weitere Informationen finden Sie unter Informationen zur GKE Control Plane Authority.

Standardmäßig Google Cloud wendet verschiedene Sicherheitsmaßnahmen auf die verwaltete Steuerungsebene an. Auf dieser Seite werden optionale Funktionen beschrieben, die Ihnen mehr Einblick in die GKE-Steuerungsebene oder mehr Kontrolle über sie geben.

Google-Zugriff auf Instanzen der Cluster-Steuerungsebene

Bei der Fehlerbehebung oder aus anderen berechtigten geschäftlichen Gründen benötigen Google-Mitarbeiter wie Site Reliability Engineers und Mitarbeiter von Cloud Customer Care möglicherweise Administratorzugriff auf die Compute Engine-Instanzen, auf denen Ihre Steuerungsebene gehostet wird. Je nach Customer Care-Supportpaket und Konfiguration bietet Access Transparency eine detaillierte Audit-Protokollierung für diesen Administratorzugriff. Mit der Zugriffsgenehmigung können Sie eine ausdrückliche Genehmigung anfordern, bevor Google-Mitarbeiter auf Ihre Ressourcen zugreifen können. Weitere Informationen zum Administratorzugriff und zu den Tools, mit denen Sie den Zugriff autorisieren und Änderungen aufzeichnen können, finden Sie unter Administratorzugriff für Google-Mitarbeiter.

Zugriffsprotokolle der Steuerungsebene

Wenn Sie die GKE Control Plane Authority aktivieren, generiert GKE Zugriffsprotokolle der Steuerungsebene , mit denen Sie optional die von Access Transparency und Access Approval generierten Audit-Logs abgleichen können. GKE fügt dem _Default Bucket in Logging Zugriffsprotokolle der Steuerungsebene hinzu, um eingehende Netzwerkverbindungen und bestimmte SSH-Ereignisse in Ihren Steuerungsebeneninstanzen aufzuzeichnen. Sie müssen die GKE Control Plane Authority in Ihrem Projekt aktivieren, um Zugriffsprotokolle der Steuerungsebene für Ihre Cluster zu generieren.

GKE generiert die folgenden Zugriffsprotokolle für die Steuerungsebene:

Das Volumen der Verbindungsprotokolle der Steuerungsebene hängt von Faktoren wie der Anzahl der Knoten im Cluster, der Anzahl der Instanzen der Steuerungsebene (regionale Cluster haben mehr Instanzen der Steuerungsebene als zonale Cluster) und davon ab, wie oft Ihre Arbeitslasten den Kubernetes API-Server aufrufen. Das Volumen der SSH-Protokolle ist gering und hängt von der Anzahl der Neustarts von Knoten ab.

Um die Verbindungen zu Ihrer Steuerungsebene zu überprüfen, suchen Sie die Zugriffsprotokolle der Steuerungsebene für Ihren Cluster und gleichen Sie sie mit Audit-Logs von Access Transparency und Access Approval ab. So können Sie bestätigen, dass alle SSH-Verbindungen zu Ihren Instanzen der Steuerungsebene auf autorisierten Administratorzugriff durch Google-Mitarbeiter zurückzuführen sind. Wenn Sie die GKE Control Plane Authority für Ihren Cluster aktivieren, ist der gesamte SSH-Zugriff von Google Mitarbeitern auf Ihre Steuerungsebene nicht interaktiv. Das bedeutet, dass bei jeder SSH Verbindung ein einzelner von Ihnen autorisierter Befehl ausgeführt wird. Wenn Sie Details auf Befehlsebene für den Administratorzugriff sehen möchten, registrieren Sie sich für Augmented Access Approval und Augmented Access Transparency. Weitere Informationen zu den Voraussetzungen und zur Registrierung erhalten Sie von Ihrem Google Cloud Account-Management-Team.

Preise

Dabei gelten folgende Preisaspekte:

Hinweis

Führen Sie die folgenden Aufgaben aus, bevor Sie beginnen:

  • Aktivieren Sie die Google Kubernetes Engine API.
    • Google Kubernetes Engine API aktivieren
  • Wenn Sie die Google Cloud CLI für diesen Task verwenden möchten, installieren und dann initialisieren Sie die gcloud CLI. Wenn Sie die gcloud CLI bereits installiert haben, rufen Sie die neueste Version mit dem gcloud components update Befehl ab. Ältere gcloud CLI-Versionen unterstützen möglicherweise nicht die Ausführung der Befehle in diesem Dokument.

  • Cloud Logging API aktivieren

    Rollen, die zum Aktivieren von APIs erforderlich sind

    Zum Aktivieren von APIs benötigen Sie die IAM-Rolle „Service Usage-Administrator“ (roles/serviceusage.serviceUsageAdmin), die die Berechtigung serviceusage.services.enable enthält. Informationen zum Zuweisen von Rollen.

    API aktivieren

  • Aktivieren Sie Access Transparency für Ihre Organisation. Eine Anleitung finden Sie unter Access Transparency aktivieren.

  • Optional können Sie Access Approval für Ihr Projekt aktivieren und den GKE-Dienst auswählen. Eine Anleitung finden Sie unter Zugriffsanfragen mit dem von Google verwalteten Signaturschlüssel überprüfen und genehmigen.

  • Prüfen Sie, ob Ihre Umgebung für die Verwendung der GKE Control Plane Authority-Features geeignet ist. Wenn Sie diese Features nutzen möchten, wenden Sie sich an Ihr Google Cloud Vertriebsteam.

Voraussetzungen

Für Zugriffsprotokolle der Steuerungsebene ist GKE-Version 1.31.1-gke.1846000 oder höher erforderlich.

Erforderliche Rollen und Berechtigungen

Bitten Sie Ihren Administrator, Ihnen die folgenden IAM-Rollen zuzuweisen, um die Berechtigungen zu erhalten, die Sie zum Aktivieren der Protokollgenerierung sowie zum Zugriff auf und zur Verarbeitung von Protokollen benötigen:

Weitere Informationen zum Zuweisen von Rollen finden Sie unter Zugriff auf Projekte, Ordner und Organisationen verwalten.

Sie können die erforderlichen Berechtigungen auch über benutzerdefinierte Rollen oder andere vordefinierte Rollen erhalten.

Zugriffsprotokolle der GKE-Cluster-Steuerungsebene aktivieren

Sie können die Generierung von Zugriffsprotokollen der Steuerungsebene für Cluster im Autopilot-Modus und im Standardmodus aktivieren, indem Sie die entsprechende Logging-Komponente aktivieren. Weitere Informationen zu den Protokolltypen der Steuerungsebene finden Sie unter GKE-Logs ansehen.

Die unterstützten Namen der Logging-Komponenten für Zugriffsprotokolle der Steuerungsebene sind:

  • SSH-Protokolle der Steuerungsebene: KCP_SSHD
  • Verbindungsprotokolle der Steuerungsebene: KCP_CONNECTION

Zugriffsprotokolle der Steuerungsebene für einen neuen Cluster aktivieren

Im folgenden Beispiel wird ein Cluster im Autopilot-Modus erstellt, bei dem beide Arten von Zugriffsprotokollen der Steuerungsebene aktiviert sind. Wenn Sie nur eine Art von Zugriffsprotokoll der Steuerungsebene aktivieren möchten, lassen Sie den entsprechenden Komponentennamen im Befehl weg.

gcloud container clusters create-auto CLUSTER_NAME \
    --location=LOCATION \
    --logging=SYSTEM,KCP_SSHD,KCP_CONNECTION

Ersetzen Sie Folgendes:

  • CLUSTER_NAME ist der Name des neuen Clusters.
  • LOCATION ist der Speicherort, an dem der Cluster erstellt werden soll.

Wenn Sie Logging-Komponenten angeben möchten, wenn Sie einen Cluster mit der GKE API erstellen, legen Sie in der projects.locations.clusters.create Methode die entsprechenden Werte im LoggingConfig Objekt der Cluster Ressource fest.

Zugriffsprotokolle der Steuerungsebene für einen vorhandenen Cluster aktivieren

So aktualisieren Sie die Logging-Konfiguration eines vorhandenen Clusters, um Zugriffsprotokolle der Steuerungsebene zu aktivieren:

  1. Suchen Sie die vorhandenen Logging-Komponenten, die von Ihrem Cluster verwendet werden.
  2. Ermitteln Sie die entsprechenden Werte, die Sie im Flag --logging in der gcloud CLI angeben müssen, damit diese Logging-Komponenten aktiviert bleiben.
  3. Aktualisieren Sie die Logging-Konfiguration Ihres Clusters, um die Zugriffsprotokolle der Steuerungsebene zusätzlich zur vorhandenen Logging-Konfiguration zu aktivieren.

Die Werte, die Sie für das Flag --logging im Befehl gcloud container clusters update angeben, unterscheiden sich von den Werten, die angezeigt werden, wenn Sie Ihren Cluster beschreiben.

  1. Prüfen Sie die vorhandene Logging-Konfiguration des Clusters:

    gcloud container clusters describe CLUSTER_NAME \
    --location=LOCATION \
    --flatten=loggingConfig \
    --format='csv[delimiter=",",no-heading](componentConfig.enableComponents)'

    Die Ausgabe sieht etwa so aus:

    SYSTEM_COMPONENTS,WORKLOADS,APISERVER,SCHEDULER,CONTROLLER_MANAGER

  2. Ermitteln Sie die gcloud CLI-Werte für das Flag --logging, die der Konfiguration der Logging-Komponente aus der Ausgabe des vorherigen Schritts entsprechen. Eine Liste der gcloud CLI-Werte, die bestimmten Logging-Komponenten entsprechen, finden Sie in der Tabelle Verfügbare Protokolle.

  3. Aktualisieren Sie die Logging-Konfiguration mit Zugriffsprotokollen der Steuerungsebene:

    gcloud container clusters update CLUSTER_NAME \
    --location=LOCATION \
    --logging=SYSTEM,EXISTING_LOGS,KCP_ACCESS_LOGS

    Ersetzen Sie Folgendes:

    • EXISTING_LOGSist eine durch Kommas getrennte Liste der Logging-Komponenten, die Ihr Cluster bereits verwendet. Geben Sie die gcloud CLI-Werte an, die diesen Logging Komponenten entsprechen und aus der Tabelle Verfügbare Protokolle stammen.

    • KCP_ACCESS_LOGSist eine durch Kommas getrennte Liste der Typen von Zugriffsprotokollen der Steuerungsebene, die für den Cluster aktiviert werden sollen:

      • Geben Sie für SSH-Protokolle der Steuerungsebene KCP_SSHD an.
      • Geben Sie für Verbindungsprotokolle der Steuerungsebene KCP_CONNECTION an.

Wenn Sie Logging-Komponenten angeben möchten, wenn Sie einen Cluster mit der GKE API aktualisieren, legen Sie in der projects.locations.clusters.update Methode die vorhandenen und neuen Werte der Logging-Komponenten im LoggingConfig Objekt der ClusterUpdate Ressource fest.

Beispiel für eine Clusteraktualisierung zum Aktivieren von Zugriffsprotokollen der Steuerungsebene

Angenommen, für einen Cluster wird nach Ausführung des Befehls gcloud container clusters describe die folgende Logging-Konfiguration angezeigt:

SYSTEM_COMPONENTS,WORKLOADS,APISERVER,SCHEDULER,CONTROLLER_MANAGER

Mit dem folgenden Befehl zur Clusteraktualisierung werden beide Arten von Zugriffsprotokollen der Steuerungsebene aktiviert, während die vorhandene Protokollkonfiguration für diesen Beispielcluster beibehalten wird:

gcloud container clusters update example-cluster \
    --location=us-central1 \
    --logging=SYSTEM,WORKLOAD,API_SERVER,SCHEDULER,CONTROLLER_MANAGER,KCP_SSHD,KCP_CONNECTION

Zugriffsprotokolle der Steuerungsebene mit Access Transparency-Logs abgleichen

Um den Zugriff auf die Steuerungsebene für einen Cluster zu überprüfen, rufen Sie die Verbindungsprotokolle der Steuerungsebene, die SSH-Protokolle der Steuerungsebene und die Access Transparency-Logs für diesen Cluster ab:

  1. Öffnen Sie in der Google Cloud Console die Seite Log-Explorer.

    Zum Log-Explorer

  2. Wenn Sie alle Protokolle für einen bestimmten Cluster abrufen möchten, einschließlich der Zugriffsprotokolle der Steuerungsebene und der Access Transparency-Logs, führen Sie die folgende Abfrage aus:

    (logName="projects/PROJECT_ID/logs/container.googleapis.com%2Fkcp-connection"
resource.labels.cluster_name="CLUSTER_NAME"
jsonPayload.connection.dest_port="22")
OR
(logName="projects/PROJECT_ID/logs/container.googleapis.com%2Fkcp-sshd"
resource.labels.cluster_name="CLUSTER_NAME")
OR
(logName="projects/PROJECT_ID/logs/cloudaudit.googleapis.com%2Faccess_transparency"
json_payload.accesses.methodName="GoogleInternal.SSH.Master"
json_payload.accesses.resourceName="//container.googleapis.com/projects/PROJECT_NUMBER/locations/LOCATION/clusters/CLUSTER_NAME")

Die Ausgabe sollte alle folgenden Protokolltypen für Ihren Cluster enthalten:

  • Access Transparency-Log
  • Verbindungsprotokoll der Steuerungsebene
  • SSH-Protokolle für jede SSH-Sitzung

Überprüfungen durchführen

Bei der primären Überprüfung geht es darum, ob alle Protokolltypen für alle SSH-Verbindungen angezeigt werden, wenn Sie die Logging-Abfrage aus dem vorherigen Abschnitt ausführen. Jedes Access Transparency-Log sollte ein entsprechendes Verbindungsprotokoll der Steuerungsebene und ein oder mehrere SSH-Protokolle haben. Diese Protokolle beziehen sich auf Aktionen, die von Personen in Ihren Instanzen der Steuerungsebene ausgeführt werden. Das Protokollvolumen sollte daher gering sein.

Optional können Sie die folgenden zusätzlichen Überprüfungen der Protokollinhalte durchführen:

  1. Prüfen Sie für jedes SSH-Protokoll der Steuerungsebene, ob in einem Zeitraum von 15 Minuten vor dem Zeitstempel des SSH-Protokolls ein Access Transparency-Log vorhanden ist. Dieser Zeitraum berücksichtigt, dass die endgültige Schließung der SSH-Sitzung mehrere Minuten nach der ersten Verbindung erfolgt, die von Access Transparency protokolliert wurde.
  2. Prüfen Sie für jedes Verbindungsprotokoll der Steuerungsebene, ob in einem Zeitraum von 5 Minuten vor dem Zeitstempel des Verbindungsprotokolls der Steuerungsebene ein Access Transparency-Log vorhanden ist.

  3. Wenn Sie Access Approval für Ihren Cluster verwenden, prüfen Sie, ob jedes Access Transparency-Log ein entsprechendes Feld accessApprovals hat. Gleichen Sie dieses Feld mit Access Approval-Anfragen für Ihren Cluster ab.

    Informationen zum Abrufen von Access Approval-Anfragen für Ihr Projekt finden Sie unter Bisherige Access Approval-Anfragen ansehen. Für Access Approval gelten möglicherweise Ausschlüsse.

  4. Optional können Sie die Signatur der signierten Access Approval-Genehmigung validieren, die mit dem Access Transparency-Log verknüpft ist.

Details zu Zugriffsprotokollen der Steuerungsebene

In diesem Abschnitt finden Sie Details und Beispiele für die Zugriffsprotokolle der Steuerungsebene, die von GKE generiert werden, wenn Google-Mitarbeiter eine Verbindung zu Ihren Instanzen der Steuerungsebene herstellen.

Verbindungsprotokolle der Steuerungsebene

GKE fügt für jede neue eingehende Netzwerkverbindung zu einer Instanz der Steuerungsebene ein Verbindungsprotokoll der Steuerungsebene hinzu. Diese Protokolle enthalten bestimmte Details wie:

  • Quell- und Ziel-IP-Adressen und -Ports
  • Verbindungsrichtung und -protokoll

Das folgende Beispiel zeigt ein Verbindungsprotokoll der Steuerungsebene:

{
  insertId: "z1eq8wonio335a5h",
  jsonPayload: {
    instance: {
      vm_name: "gke-dee49f0d6fa34ce3a2ac-f513-d195-vm",
      zone: "us-central1-c"
    },
    cluster: {
      cluster_id: "CLUSTER_ID",
      cluster_urn: "//container.googleapis.com/projects/PROJECT_NUMBER/locations/us-central1-c/clusters/CLUSTER_NAME"
    },
    connection: {
      state: "NEW",
      src_ip: "192.0.2.100",
      src_port: 32774,
      dest_ip: "203.0.113.12",
      dest_port: 22,
      direction: "INGRESS"
      protocol: "TCP"
    },
  }
  logName: "projects/PROJECT_ID/logs/container.googleapis.com%2Fkcp-connection",
  receiveTimestamp: "2024-04-11T04:08:01.883070399Z",
  resource: {
    labels: {
      cluster_name: "CLUSTER_NAME",
      location: "us-central1-c",
      project_id: "PROJECT_ID"
    }
    type: "gke_cluster",
  }
  severity: "NOTICE",
  timestamp: "2024-04-11T04:07:59.019330Z"
}

Die folgenden Felder im Logeintrag sind relevant für die Überprüfung der Aktionen von Google:

  • cluster.cluster_urn: Der vollständig qualifizierte Ressourcenbezeichner des Clusters. Dieser Bezeichner hat das Format //container.googleapis.com/projects/PROJECT_NUMBER/locations/LOCATION/clusters/CLUSTER_NAME, mit den folgenden Variablen:

    • PROJECT_NUMBERist die numerische Projektnummer des Projekts Ihres Clusters.
    • LOCATION ist der Google Cloud Speicherort Ihres Clusters.
    • CLUSTER_NAME ist der Name Ihres Clusters.

  • connection: Details zum Verbindungsversuch. Dieses Feld enthält die folgenden Informationen:

    • state: der Status der Verbindung. Bei neuen Verbindungen ist der Wert NEW.
    • src_ip: die IP-Adresse der Verbindungsquelle.
    • src_port: die Portnummer der Verbindungsquelle.
    • dest_ip: die interne IP-Adresse Ihrer VM der Steuerungsebene.
    • dest_port: die Zielportnummer.
    • direction: die Verbindungsrichtung. Der Wert ist immer INGRESS.
    • protocol: das IP-Protokoll, z. B. TCP.

SSH-Protokolle der Steuerungsebene

GKE fügt SSH-Protokolle der Steuerungsebene für Ereignisse im Zusammenhang mit SSH-Verbindungen zu Instanzen der Steuerungsebene hinzu. GKE zeichnet die folgenden Ereignisse auf:

  • SSH-Schlüssel für einen Nutzer akzeptiert
  • Status der Sitzung von 0 in 1 geändert, was darauf hinweist, dass sich der Nutzer erfolgreich angemeldet hat
  • SSH-Sitzung geöffnet
  • SSH-Sitzung geschlossen
  • Status der Sitzung von 1 in 0 geändert, was darauf hinweist, dass sich der Nutzer abgemeldet hat
  • SSH-Sitzung fehlgeschlagen

Das folgende SSH-Protokoll der Steuerungsebene bezieht sich beispielsweise auf das Öffnen einer SSH-Sitzung:

{
  insertId: "8llczemdulwbbwpa",
  jsonPayload: {
    instance: {
      vm_name: "gke-06cb920c609941c0a5ce-6840-40e9-vm",
      zone: "us-central1-c"
    },
    cluster: {
      cluster_id: "891e6d12889747748c1ac16ffcc6cb7c0a96450b36864eb680917c119fd801d0",
      cluster_urn: "//container.googleapis.com/projects/PROJECT_NUMBER/locations/us-central1/clusters/CLUSTER_NAME",
    },
    message: "pam_unix(sshd:session): session opened for user REDACTED by (uid=0)",
  },
  logName: "projects/PROJECT_ID/logs/container.googleapis.com%2Fkcp-ssh",
  receiveTimestamp: "2024-04-09T13:21:55.231436462Z"
  resource: {
    type: "gke_cluster",
    labels: {
      cluster_name: "CLUSTER_NAME",
      location: "us-central1",
      project_id: "PROJECT_ID"
    }
  },
  severity: "NOTICE",
  timestamp: "2024-04-09T13:21:50.742246Z"
}

Die folgenden Felder im Logeintrag sind relevant für die Überprüfung der Aktionen von Google:

  • cluster.cluster_urn: Der vollständig qualifizierte Ressourcenbezeichner des Clusters. Dieser Bezeichner hat das Format //container.googleapis.com/projects/PROJECT_NUMBER/locations/LOCATION/clusters/CLUSTER_NAME, mit den folgenden Variablen:

    • PROJECT_NUMBERist die numerische Projektnummer des Projekts Ihres Clusters.
    • LOCATION ist der Google Cloud Speicherort Ihres Clusters.
    • CLUSTER_NAME ist der Name Ihres Clusters.

  • message: Details zur SSH-Verbindung.

Zugriffsprotokolle der Steuerungsebene deaktivieren

  1. Wenn Sie die spezifischen Protokolltypen sehen möchten, die von Ihrem Cluster verwendet werden, führen Sie den folgenden Befehl aus:

    gcloud container clusters describe CLUSTER_NAME \
    --location=LOCATION \
    --flatten=loggingConfig \
    --format='csv[delimiter=",",no-heading](componentConfig.enableComponents)'

    Die Ausgabe sieht etwa so aus:

    SYSTEM_COMPONENTS,WORKLOADS,API_SERVER,SCHEDULER,CONTROLLER_MANAGER,KCP_SSHD,KCP_CONNECTION

  2. Führen Sie den folgenden Befehl aus, um die Zugriffsprotokolle der Steuerungsebene für einen Cluster zu deaktivieren:

    gcloud container clusters update CLUSTER_NAME \
    --location=LOCATION \
    --logging=SYSTEM,WORKLOAD,API_SERVER,SCHEDULER,CONTROLLER_MANAGER

Geben Sie im Flag --logging die Logging-Komponenten aus der Ausgabe des vorherigen Befehls an. Mit diesem Beispielbefehl werden die Zugriffsprotokolle der Steuerungsebene deaktiviert, andere Protokolle der Steuerungsebenenkomponenten bleiben jedoch aktiviert.

Wenn Sie Logging-Komponenten mit der GKE API deaktivieren möchten, legen Sie die entsprechenden Werte im LoggingConfig Objekt der ClusterUpdate Ressource in der projects.locations.clusters.update Methode fest.

Nächste Schritte