Google-Verbindungen zur GKE-Steuerungsebene prüfen

Auf dieser Seite wird beschrieben, wie Sie Verbindungen prüfen, die von Google-Mitarbeitern zur Steuerungsebene Ihres Google Kubernetes Engine-Clusters (GKE) hergestellt wurden, indem Sie GKE-Logs mit Access Transparency-Logs abgleichen.

In Access Transparency-Logs werden die Aktionen der Google-Mitarbeiter aufgezeichnet, wenn sie auf Ihre Inhalte zugreifen. Dieser Leitfaden richtet sich an Sicherheitsadministratoren, die den Inhalt von Access Transparency-Logs und zugehörige Zugriffsgenehmigungen durch Abgleich mit zusätzlichen Logging-Quellen aus GKE zusätzlich überprüfen möchten. Diese Bestätigung 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 der optionalen Funktionen der Steuerungsebene in GKE beschrieben, mit denen Sie Aufgaben wie die Überprüfung des Sicherheitsstatus der Steuerungsebene oder die Konfiguration der Verschlüsselung und Anmeldedatensignatur in der Steuerungsebene mit von Ihnen verwalteten Schlüsseln ausführen können. Weitere Informationen finden Sie unter GKE Control Plane Authority.

Standardmäßig werden in Google Cloud verschiedene Sicherheitsmaßnahmen auf die verwaltete Steuerungsebene angewendet. Auf dieser Seite werden optionale Funktionen beschrieben, mit denen Sie die GKE-Steuerungsebene besser im Blick behalten oder steuern können.

Google-Zugriff auf Instanzen der Clustersteuerungsebene

Bei der Fehlerbehebung oder aus anderen berechtigten geschäftlichen Gründen benötigen Google-Mitarbeiter wie Site Reliability Engineers und Cloud-Kundenservicemitarbeiter möglicherweise Administratorzugriff auf die Compute Engine-Instanzen, auf denen Ihre Kontrollebene gehostet wird. Je nach Supportpaket und Konfiguration des Kundensupports bietet Access Transparency detaillierte Audit-Logs für diesen administrativen Zugriff. Mit der Zugriffsgenehmigung können Sie eine ausdrückliche Genehmigung verlangen, 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 erfassen können, finden Sie unter Administratorzugriff für Google-Mitarbeiter.

Logs für den Zugriff auf die Steuerungsebene

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

GKE generiert die folgenden Zugriffsprotokolle für die Steuerungsebene:

Die Anzahl der Steuerungsebenen-Verbindungsprotokolle hängt von Faktoren wie der Anzahl der Knoten im Cluster, der Anzahl der Steuerungsebeneninstanzen (regionale Cluster haben mehr Steuerungsebeneninstanzen als zonale Cluster) und der Häufigkeit ab, mit der Ihre Arbeitslasten den Kubernetes API-Server aufrufen. Das Volumen der SSH-Protokolle ist gering und hängt von der Anzahl der Knotenneustarts ab.

Um die Verbindungen zu Ihrer Steuerungsebene zu überprüfen, suchen Sie die Zugriffslogs der Steuerungsebene für Ihren Cluster und gleichen Sie diese mit den Prüflogs von Access Transparency und Access Approval ab. So können Sie prüfen, ob alle SSH-Verbindungen zu Ihren Steuerungsebeneninstanzen auf autorisierten Administratorzugriff durch Google-Mitarbeiter zurückzuführen sind. Wenn Sie die GKE-Steuerungsebene für Ihren Cluster aktivieren, ist der gesamte SSH-Zugriff von Google-Mitarbeitern auf Ihre Steuerungsebene nicht interaktiv. Das bedeutet, dass über jede SSH-Verbindung ein einzelner Befehl ausgeführt wird, den Sie autorisieren.

Preise

Dabei gelten folgende Preisaspekte:

Hinweise

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 diese Aufgabe verwenden möchten, müssen Sie die gcloud CLI installieren und dann initialisieren. Wenn Sie die gcloud CLI bereits installiert haben, rufen Sie die neueste Version mit gcloud components update ab.

Voraussetzungen

Für Zugriffsprotokolle der Steuerungsebene ist die 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 Protokollerstellung und 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 für die GKE-Cluster-Steuerungsebene aktivieren

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

Die unterstützten Namen der Logging-Komponenten für Logs zum Zugriff auf die Steuerungsebene sind:

  • SSH-Logs der Steuerungsebene: KCP_SSHD
  • Logs der Steuerungsebene: KCP_CONNECTION

Zugriffsprotokolle für die Steuerungsebene in einem neuen Cluster aktivieren

Im folgenden Beispiel wird ein Cluster im Autopilot-Modus erstellt, bei dem beide Arten von Zugriffsprotokollen für die Steuerungsebene aktiviert sind. Wenn Sie nur einen bestimmten Zugriffsprotokolltyp für die Steuerungsebene aktivieren möchten, lassen Sie den entsprechenden Komponentennamen aus dem 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: Der Speicherort, an dem der Cluster erstellt werden soll.

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

Zugriffsprotokolle für die Steuerungsebene in einem vorhandenen Cluster aktivieren

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

  1. Suchen Sie die vorhandenen Logging-Komponenten, die in Ihrem Cluster verwendet werden.
  2. Ermitteln Sie die entsprechenden Werte, die Sie in der gcloud CLI im Flag --logging angeben müssen, damit diese Protokollierungskomponenten aktiviert bleiben.
  3. Aktualisieren Sie die Logging-Konfiguration Ihres Clusters, um die Protokolle für den Zugriff auf die Steuerungsebene neben Ihrer 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 Sie sehen, 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 in 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 Protokollierungskomponenten entsprechen, finden Sie in der Tabelle Verfügbare Protokolle.

  3. Aktualisieren Sie die Logging-Konfiguration mit Logs für den Zugriff auf die Steuerungsebene:

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

    Ersetzen Sie Folgendes:

    • EXISTING_LOGS: eine durch Kommas getrennte Liste der Logging-Komponenten, die in Ihrem Cluster bereits verwendet werden. Geben Sie die gcloud CLI-Werte an, die diesen Protokollierungskomponenten entsprechen. Sie finden sie in der Tabelle Verfügbare Protokolle.

    • KCP_ACCESS_LOGS: eine durch Kommas getrennte Liste der Logtypen für die Steuerungsebene, die für den Cluster aktiviert werden sollen:

      • Geben Sie für SSH-Logs 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 Methode projects.locations.clusters.update die Werte der vorhandenen und neuen Logging-Komponenten im LoggingConfig-Objekt der ClusterUpdate-Ressource fest.

Beispiel für ein Clusterupdate zum Aktivieren von Protokollen für den Zugriff auf die Steuerungsebene

Angenommen, für einen Cluster gilt für den Befehl gcloud container clusters describe die folgende Logging-Konfiguration:

SYSTEM_COMPONENTS,WORKLOADS,APISERVER,SCHEDULER,CONTROLLER_MANAGER

Mit dem folgenden Befehl zum Aktualisieren des Clusters werden beide Arten von Protokollen für den Zugriff auf die 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 Steuerebene mit Access Transparency-Logs vergleichen

Wenn Sie den Zugriff auf die Steuerungsebene für einen Cluster prüfen möchten, rufen Sie die Verbindungsprotokolle, die SSH-Protokolle und die Access Transparency-Protokolle für diesen Cluster ab:

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

    Zum Log-Explorer

  2. Wenn Sie alle Logs für einen bestimmten Cluster abrufen möchten, einschließlich der Logs für den Zugriff auf die Kontrollebene und 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

Prüfen Sie zuerst, ob Sie alle Logtypen für alle SSH-Verbindungen sehen, 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-Logs haben. Diese Protokolle enthalten Aktionen, die von Nutzern in Ihren Instanzen der Steuerungsebene ausgeführt werden. Das Protokollvolumen sollte daher gering sein.

Optional können Sie die folgenden zusätzlichen Prüfungen des Log-Inhalts ausführen:

  1. Prüfen Sie für jedes SSH-Log der Steuerungsebene, ob es innerhalb von 15 Minuten vor dem Zeitstempel des SSH-Logs ein Access Transparency-Log gibt. Dieser Zeitraum berücksichtigt die endgültige Schließung der SSH-Sitzung, die mehrere Minuten nach dem Protokollieren der ursprünglichen Verbindung durch Access Transparency erfolgt.
  2. Prüfen Sie für jedes Verbindungsprotokoll der Steuerungsebene, ob es in einem 5-Minuten-Fenster vor dem Zeitstempel des Verbindungsprotokolls der Steuerungsebene ein Access Transparency-Protokoll gibt.

  3. Wenn Sie die Zugriffsgenehmigung für Ihren Cluster verwenden, prüfen Sie, ob jedes Access Transparency-Log ein entsprechendes accessApprovals-Feld hat. Vergleichen Sie dieses Feld mit den Anfragen für die Zugriffsgenehmigung für Ihren Cluster.

    Wie Sie Anfragen für die Zugriffsgenehmigung für Ihr Projekt erhalten, erfahren Sie unter Vergangene Anfragen für die Zugriffsgenehmigung ansehen. Für die Zugriffsgenehmigung gelten möglicherweise Ausschlüsse.

  4. Optional können Sie die Signatur der unterzeichneten Zugriffsgenehmigung prüfen, die mit dem Access Transparency-Log verknüpft ist.

Details zum Zugriffsprotokoll 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 Steuerungsebenen-Instanzen herstellen.

Logs der Steuerungsebene

GKE fügt für jede neue eingehende Netzwerkverbindung zu einer Steuerungsebenen-Instanz ein Steuerungsebenen-Verbindungsprotokoll hinzu. Diese Protokolle enthalten spezifische Details wie die folgenden:

  • 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 für die Überprüfung der Maßnahmen von Google relevant:

  • cluster.cluster_urn: Die voll qualifizierte Ressourcenkennzeichnung des Clusters. Diese Kennung hat das Format //container.googleapis.com/projects/PROJECT_NUMBER/locations/LOCATION/clusters/CLUSTER_NAME mit den folgenden Variablen:

    • PROJECT_NUMBER: die numerische Projektnummer Ihres Clusterprojekts.
    • LOCATION: den Google Cloud-Speicherort Ihres Clusters.
    • CLUSTER_NAME: Der Name Ihres Clusters.

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

    • state: den 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 der VM der Steuerungsebene.
    • dest_port: die Zielportnummer.
    • direction: die Verbindungsrichtung. Der Wert ist immer INGRESS.
    • protocol: das IP-Protokoll, z. B. TCP.

SSH-Logs der Steuerungsebene

GKE fügt SSH-Logs für die 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
  • Der Sitzungsstatus hat sich von 0 auf 1 geändert, was bedeutet, dass sich der Nutzer erfolgreich angemeldet hat.
  • SSH-Sitzung geöffnet
  • SSH-Sitzung geschlossen
  • Der Sitzungsstatus hat sich von „1“ in „0“ geändert, was bedeutet, dass sich der Nutzer abgemeldet hat.
  • SSH-Sitzung fehlgeschlagen

Das folgende SSH-Log 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 für die Überprüfung der Maßnahmen von Google relevant:

  • cluster.cluster_urn: Die voll qualifizierte Ressourcenkennzeichnung des Clusters. Diese Kennung hat das Format //container.googleapis.com/projects/PROJECT_NUMBER/locations/LOCATION/clusters/CLUSTER_NAME mit den folgenden Variablen:

    • PROJECT_NUMBER: die numerische Projektnummer Ihres Clusterprojekts.
    • LOCATION: den Google Cloud-Speicherort Ihres Clusters.
    • CLUSTER_NAME: Der Name Ihres Clusters.

  • message: Details zur SSH-Verbindung.

Zugriffsprotokolle für die Steuerungsebene deaktivieren

  1. Führen Sie den folgenden Befehl aus, um die spezifischen Protokolltypen aufzurufen, die in Ihrem Cluster verwendet werden:

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

    Die Ausgabe sieht in 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 Protokolle zu Zugriffen auf die Steuerungsebene deaktiviert, andere Protokolle zu Komponenten der Steuerungsebene 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