Google-Verbindungen zur GKE-Steuerungsebene prüfen

.

Auf dieser Seite wird beschrieben, wie Sie Verbindungen von Google-Mitarbeitern zu Ihrer GKE-Clustersteuerungsebene (Google Kubernetes Engine) überprüfen, 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 zugehörigen Zugriffsgenehmigungen durch Abgleich mit zusätzlichen Protokollierungsquellen aus GKE überprüfen möchten. 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 Steuerungsebenenfunktionen in GKE beschrieben, mit denen Sie Aufgaben wie das Überprüfen des Sicherheitsstatus der Steuerungsebene oder das Konfigurieren der Verschlüsselung und der Anmeldedatensignierung in der Steuerungsebene mit von Ihnen verwalteten Schlüsseln ausführen können. Weitere Informationen finden Sie unter GKE Control Plane Authority.

Standardmäßig wendet Google Cloud verschiedene Sicherheitsmaßnahmen auf die verwaltete Steuerungsebene an. Auf dieser Seite werden optionale Funktionen beschrieben, mit denen Sie mehr Einblick in die GKE-Steuerungsebene erhalten oder mehr Kontrolle darüber haben.

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 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 administrativen Zugriff. Mit Access Approval können Sie festlegen, dass eine ausdrückliche Genehmigung erforderlich ist, 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 für die Steuerungsebene, die Sie optional verwenden können, um die von Access Transparency und Access Approval generierten Audit-Logs abzugleichen. GKE fügt dem _Default-Bucket in Logging Logs für den Zugriff auf die Steuerungsebene hinzu, um eingehende Netzwerkverbindungen und bestimmte SSH-Ereignisse in Ihren Steuerungsebeneninstanzen aufzuzeichnen. Sie müssen die GKE-Steuerungsebenenautorität in Ihrem Projekt aktivieren, um Zugriffsprotokolle für die Steuerungsebene für Ihre Cluster zu generieren.

GKE generiert die folgenden Zugriffslogs 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-Logs ist gering und hängt von der Anzahl der Neustarts des Knotens ab.

Um die Verbindungen zu Ihrer Steuerungsebene zu prüfen, suchen Sie die Zugriffsprotokolle der Steuerungsebene für Ihren Cluster und gleichen Sie diese Protokolle mit den Audit-Logs von Access Transparency und Access Approval ab. So können Sie bestätigen, dass alle SSH-Verbindungen zu Ihren Steuerungsebeneninstanzen auf autorisierten administrativen Zugriff durch Google-Mitarbeiter zurückzuführen sind. Wenn Sie die GKE-Steuerungsebenenautorität für Ihren Cluster aktivieren, ist der gesamte SSH-Zugriff durch Google-Mitarbeiter auf Ihre Steuerungsebene nicht interaktiv. Das bedeutet, dass bei jeder SSH-Verbindung ein einzelner Befehl ausgeführt wird, den Sie autorisieren.

Preise

Dabei gelten folgende Preisaspekte:

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

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.

  • Aktivieren Sie die Cloud Logging API.

    Enable the API

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

  • Aktivieren Sie optional Access Approval für Ihr Projekt und wählen Sie den GKE-Dienst aus. Eine Anleitung finden Sie unter Zugriffsanfragen mit dem von Google verwalteten Signaturschlüssel prüfen und genehmigen.

  • Prüfen Sie, ob Ihre Umgebung die Voraussetzungen für die Verwendung von GKE Control Plane Authority-Funktionen erfüllt. Wenn Sie diese Funktionen aktivieren möchten, wenden Sie sich an Ihr Google Cloud Vertriebsteam.

Voraussetzungen

Für Zugriffslogs 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 Protokollgenerierung sowie zum Aufrufen und Verarbeiten 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 Steuerungsebene des GKE-Cluster aktivieren

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

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

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

Zugriffsprotokolle für die Steuerungsebene in einem neuen Cluster aktivieren

Im folgenden Beispiel wird ein Cluster im Autopilot-Modus mit beiden Arten von Zugriffsprotokollen für die Steuerungsebene erstellt. Wenn Sie nur einen Typ von Zugriffsprotokoll für die 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: Der Standort, an dem der Cluster erstellt werden soll.

Wenn Sie beim Erstellen eines Clusters mit der GKE API Protokollierungskomponenten 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 für einen vorhandenen Cluster aktivieren

Wenn Sie die Logging-Konfiguration eines vorhandenen Clusters aktualisieren möchten, um Zugriffsprotokolle für die Steuerungsebene zu aktivieren, müssen Sie Folgendes tun:

  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 Protokollierungskomponenten aktiviert bleiben.
  3. Aktualisieren Sie die Logging-Konfiguration Ihres Clusters, um die Zugriffsprotokolle der 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 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 den Zugriffslogs der 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 Ihr Cluster bereits verwendet. Achten Sie darauf, dass Sie die gcloud CLI-Werte angeben, die den Protokollierungskomponenten aus der Tabelle Verfügbare Logs entsprechen.

    • KCP_ACCESS_LOGS: Eine durch Kommas getrennte Liste der Zugriffsprotokolltypen 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 beim Aktualisieren eines Clusters mit der GKE API Protokollierungskomponenten angeben möchten, legen Sie in der Methode projects.locations.clusters.update die vorhandenen - und neuen Werte für die Protokollierungskomponente im LoggingConfig-Objekt der ClusterUpdate-Ressource fest.

Beispiel für ein Clusterupdate zum Aktivieren von Zugriffsprotokollen der Steuerungsebene

Angenommen, für einen Cluster hat der 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 Zugriffsprotokollen für 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

Steuerungsebenen-Zugriffsprotokolle mit Access Transparency-Logs abgleichen

So prüfen Sie den Zugriff auf die Steuerungsebene für einen Cluster: Rufen Sie die Verbindungsprotokolle der Steuerungsebene, die SSH-Protokolle der Steuerungsebene und die Access Transparency-Protokolle für diesen Cluster ab:

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

    Zum Log-Explorer

  2. Wenn Sie alle Logs für einen bestimmten Cluster abrufen möchten, einschließlich der Control Plane-Zugriffsprotokolle 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 Arten von Logs für Ihren Cluster enthalten:

  • Access Transparency-Log
  • Log der Verbindung zur Steuerungsebene
  • SSH-Logs 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 Log für die Verbindung zur Steuerungsebene und ein oder mehrere SSH-Logs haben. Diese Logs beziehen sich auf Aktionen, die von Menschen in Ihren Instanzen der Steuerungsebene ausgeführt werden. Das Logvolumen sollte daher gering sein.

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

  1. Prüfen Sie für jedes SSH-Log der Steuerungsebene, ob in einem 15-Minuten-Zeitfenster vor dem Zeitstempel des SSH-Logs 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 Log der Steuerungsebene, ob innerhalb von fünf Minuten vor dem Zeitstempel des Logs der Steuerungsebene ein Access Transparency-Log vorhanden ist.

  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.

    Informationen dazu, wie Sie Zugriffsgenehmigungsanfragen für Ihr Projekt erhalten, finden Sie unter Bisherige Anfragen für Zugriffsgenehmigungen ansehen. Für die Zugriffsgenehmigung gelten möglicherweise Ausschlüsse.

  4. Optional können Sie die Signatur der signierten Zugriffsgenehmigung validieren, die dem Access Transparency-Log zugeordnet ist.

Details zum Zugriffslog 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.

Logs der Verbindung zur Steuerungsebene

GKE fügt für jede neue eingehende Netzwerkverbindung zu einer Steuerungsebeneninstanz ein Verbindungsprotokoll der Steuerungsebene hinzu. Diese Logs enthalten bestimmte Details wie die folgenden:

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

Das folgende Beispiel zeigt ein Protokoll für die Verbindung 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 Aktionen von Google relevant:

  • cluster.cluster_urn: Der voll qualifizierte Ressourcen-Identifier des Clusters. Diese Kennzeichnung 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 Google Cloud 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 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 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
  • Der Status der Sitzung wurde von 0 zu 1 geändert. Das bedeutet, dass sich der Nutzer erfolgreich angemeldet hat.
  • SSH-Sitzung geöffnet
  • SSH-Sitzung geschlossen
  • Der Sitzungsstatus hat sich von 1 zu 0 geändert. Das bedeutet, dass sich der Nutzer abgemeldet hat.
  • SSH-Sitzung fehlgeschlagen

Das folgende SSH-Log der Steuerungsebene bezieht sich beispielsweise auf eine SSH-Sitzung, die geöffnet wird:

{
  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 Aktionen von Google relevant:

  • cluster.cluster_urn: Der voll qualifizierte Ressourcen-Identifier des Clusters. Diese Kennzeichnung 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 Google Cloud Standort 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 Logtypen anzuzeigen, die Ihr Cluster verwendet:

    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 Objekt LoggingConfig der Ressource ClusterUpdate in der Methode projects.locations.clusters.update fest.

Nächste Schritte