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 der Google-Mitarbeiter aufgezeichnet, wenn sie auf Ihre Inhalte zugreifen. Diese Anleitung 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 die Steuerungsebene zu schützen.

Machen Sie sich mit den folgenden Konzepten vertraut:

Auf dieser Seite wird ein Teil einer Reihe optionaler Steuerungsebenen-Features in GKE beschrieben, mit denen Sie Aufgaben wie das Überprüfen der Sicherheit der Steuerungsebene oder das Konfigurieren der Verschlüsselung und der Signierung von Anmeldedaten in 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 Cloud de Confiance wendet verschiedene Sicherheitsmaßnahmen auf die verwaltete Steuerungsebene an. Auf dieser Seite werden optionale Funktionen beschrieben, die Ihnen mehr Einblick in die GKE-Steuerungsebene geben oder Ihnen mehr Kontrolle darüber ermöglichen.

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 Cloud Customer Care-Mitarbeiter möglicherweise Administratorzugriff auf die Compute Engine-Instanzen, auf denen Ihre Steuerungsebene gehostet wird. Je nach Customer Care-Supportpaket und Konfiguration bietet Access Transparency detaillierte Audit-Logs 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 Bucket _Default in Logging Zugriffs protokolle der Steuerungsebene hinzu, um eingehende Netzwerkverbindungen und bestimmte SSH-Ereignisse in Ihren Steuerungsebenen-Instanzen 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:

Die Anzahl 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. Die Anzahl der SSH-Protokolle ist gering und hängt von der Anzahl der Knotenstarts ab.

Um die Verbindungen zur 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 Steuerungsebenen-Instanzen 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 Cloud de Confiance by S3NS Account-Management-Team.

Preise

Dabei gelten folgende Preisaspekte:

  • Für Zugriffsprotokolle der Steuerungsebene gelten die Preise für Logging.
  • Access Transparency ist in bestimmten Customer Care-Abos enthalten. Weitere Informationen finden Sie unter Preise für Access Transparency.

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 diese Aufgabe 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.

  • Aktivieren Sie die Cloud Logging API.

    Rollen, die zum Aktivieren von APIs erforderlich sind

    Zum Aktivieren von APIs benötigen Sie die Berechtigung serviceusage.services.enable. Wenn Sie das Projekt erstellt haben, haben Sie diese Berechtigung wahrscheinlich bereits über die Rolle „Inhaber“ (roles/owner). Andernfalls können Sie diese Berechtigung über die Rolle „Service Usage-Administrator“ (roles/serviceusage.serviceUsageAdmin) erhalten. 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 von GKE Control Plane Authority-Features geeignet ist. Wenn Sie diese Features nutzen möchten, wenden Sie sich an Ihr Cloud de Confiance 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 Loggenerierung sowie zum Zugriff auf und zur Verarbeitung von Logs benötigen:

  • Aktivieren Sie die Protokollierung von Verbindungen der Steuerungsebene in Ihrem Cluster: Kubernetes Engine-Clusteradministrator (roles/container.clusterAdmin) für Ihr Projekt
  • Zugriff auf Logs und Verwendung von Logs Explorer und Observability Analytics: Logs-Betrachter (roles/logging.viewer) für Ihr Projekt
  • Aktivieren Sie Access Transparency für die Organisation: Access Transparency-Administrator (roles/axt.admin) für Ihre Organisation

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 Logtypen der Steuerungsebene finden Sie unter GKE-Logs ansehen.

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

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

Zugriffsprotokolle der Steuerungsebene in einem 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 Standort, 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 in einem 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, um diese Logging-Komponenten aktiviert zu lassen.
  3. Aktualisieren Sie die Logging-Konfiguration des Clusters, um die Zugriffsprotokolle der Steuerungsebene neben der 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 beim Beschreiben des Clusters angezeigt werden.

  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 Logs.

  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 bereits von Ihrem Cluster verwendet werden. Geben Sie die gcloud CLI-Werte an, die diesen Logging Komponenten entsprechen und aus der Tabelle Verfügbare Logs 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 Werte für die vorhandenen und neuen 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 Logkonfiguration 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 Cloud de Confiance Console die Seite Logs Explorer.

    Zum Log-Explorer

  2. Führen Sie die folgende Abfrage aus, um alle Logs für einen bestimmten Cluster abzurufen, einschließlich der Zugriffsprotokolle der Steuerungsebene und der Access Transparency-Logs:

    (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 Logtypen 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 Logtypen 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 Logs beziehen sich auf Aktionen, die von Personen in Ihren Steuerungsebenen-Instanzen ausgeführt werden. Das Logvolumen sollte daher gering sein.

Optional können Sie die folgenden zusätzlichen Überprüfungen der Log-Inhalte 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 von Access Transparency protokollierten Verbindung erfolgt.
  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 Frühere Anfragen für die Zugriffsgenehmigung ansehen. Für Access Approval gelten möglicherweise Ausschlüsse.

  4. Optional können Sie die Signatur der signierten Zugriffsgenehmigung 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 Steuerungsebenen-Instanzen herstellen.

Verbindungsprotokolle der Steuerungsebene

GKE fügt für jede neue eingehende Netzwerkverbindung zu einer Steuerungsebenen-Instanz 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 Ressourcenname des Clusters. Diese ID 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: der Cloud de Confiance Standort Ihres Clusters.
    • CLUSTER_NAME: 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 Steuerungsebenen-VM.
    • 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 Steuerungsebenen-Instanzen 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 hindeutet, 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 hindeutet, 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 Ressourcenname des Clusters. Diese ID 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: der Cloud de Confiance Standort Ihres Clusters.
    • CLUSTER_NAME: der Name Ihres Clusters.

  • message: Details zur SSH-Verbindung.

Zugriffsprotokolle der Steuerungsebene deaktivieren

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

    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 Steuerungsebenen-Komponenten 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