Logging von Netzwerkrichtlinien verwenden

Autopilot Standard

---

Auf dieser Seite wird erläutert, wie Sie Netzwerkrichtlinien-Logging für Google Kubernetes Engine (GKE) verwenden. Kubernetes-Netzwerkrichtlinien geben den Netzwerktraffic an, den Pods senden und empfangen dürfen. Mit dem Logging von Netzwerkrichtlinien können Sie aufzeichnen, wann eine Verbindung durch eine Netzwerkrichtlinie zugelassen oder abgelehnt wird. Mit dem Logging von Netzwerkrichtlinien können Sie Probleme mit Netzwerkrichtlinien beheben.

Übersicht

Mithilfe von Netzwerkrichtlinien-Logging können Sie:

• Prüfen, ob Ihre Netzwerkrichtlinien wie erwartet funktionieren.
• Ermitteln, welche Pods in Ihrem Cluster mit dem Internet kommunizieren.
• Sich damit vertraut machen, welche Namespaces miteinander kommunizieren.
• Einen Denial-of-Service-Angriff erkennen

Logs von Netzwerkrichtlinien werden in Cloud Logging hochgeladen, um das Speichern, Suchen, die Analyse und Benachrichtigungen zu ermöglichen, wenn Cloud Logging aktiviert ist. Cloud Logging ist in neuen Clustern standardmäßig aktiviert. Weitere Informationen finden Sie unter Logging und Monitoring für GKE konfigurieren.

Voraussetzungen

• Das Logging von Netzwerkrichtlinien ist nur bei Clustern verfügbar, GKE Dataplane V2 verwenden.
• Für das Logging von Netzwerkrichtlinien ist die Google Cloud CLI-Version 303.0.0 oder höher erforderlich.
• Das Logging von Netzwerkrichtlinien wird für Windows Server-Knotenpools nicht unterstützt.

Preise

• Es fallen für das Logging von Netzwerkrichtlinien keine Gebühren an.

• Wenn Sie Ihre Logs in Cloud Logging speichern, gelten die Standardgebühren für Cloud Logging.

• Logs können zu Pub/Sub, Cloud Storage oder BigQuery weitergeleitet werden. Für Pub/Sub, Cloud Storage und BigQuery können Gebühren anfallen. Weitere Informationen finden Sie unter Routing und Speicher – Übersicht

Logging von Netzwerkrichtlinien konfigurieren

Sie konfigurieren die Einstellungen für das Netzwerkrichtlinien-Logging, indem Sie das Objekt NetworkLogging in Ihrem Cluster bearbeiten. GKE erstellt in neuen Dataplane V2-Clustern automatisch ein NetworkLogging-Objekt namens default. Pro Cluster ist nur ein NetworkLogging-Objekt zulässig, das nicht umbenannt werden kann.

Sie können das Logging erlaubter Verbindungen und das Logging abgelehnter Verbindungen separat konfigurieren. Sie können das Logging auch für einige Netzwerkrichtlinien selektiv aktivieren. Das folgende Beispiel zeigt die Spezifikation NetworkLogging mit Einstellungen, mit denen alle zugelassenen und abgelehnten Verbindungen protokolliert werden:

kind: NetworkLogging
apiVersion: networking.gke.io/v1alpha1
metadata:
  name: default
spec:
  cluster:
    allow:
      log: true
      delegate: false
    deny:
      log: true
      delegate: false

Verwenden Sie kubectl, um Ihre Konfiguration zu bearbeiten:

kubectl edit networklogging default

Hinweis: Wenn Sie den Traffic innerhalb von Cloud Service Mesh mit Netzwerkrichtlinien beschränken, stellen Sie Ihre Netzwerkrichtlinien bereit, bevor Sie Cloud Service Mesh in einem Namespace aktivieren. Andernfalls sind lange laufende Verbindungen zwischen Pods im Mesh-Netzwerk möglicherweise bereits erstellt worden und durch die Aktivierung von neuen Netzwerkrichtlinien werden bestehende Verbindungen nicht geschlossen.

NetworkLogging-Spezifikation

Die Spezifikation des NetworkLogging-Objekts hat das YAML-Format. Dieses Format wird in der folgenden Tabelle beschrieben:

Feld	Typ	Beschreibung
cluster.allow	struct	Einstellungen für erlaubte Logging-Verbindungen. Feld Typ Beschreibung log bool Wenn true festgelegt ist, werden zulässige Verbindungen im Cluster protokolliert. Andernfalls werden zugelassene Verbindungen nicht protokolliert. Im Logeintrag werden Netzwerkrichtlinien aufgeführt, die den Pod auswählen und eine mit der Verbindung übereinstimmende Regel haben. delegate bool Bei false werden alle zugelassenen Verbindungen protokolliert. Wenn mehrere Netzwerkrichtlinien eine Verbindung zulassen, werden alle übereinstimmenden Richtlinien im Logeintrag aufgeführt. Bei true werden zulässige Verbindungen nur dann protokolliert, wenn sie von einer Netzwerkrichtlinie mit der Logging-Annotation policy.network.gke.io/enable-logging: "true" zugelassen werden. Wenn mehrere Netzwerkrichtlinien eine Verbindung zulassen, werden alle übereinstimmenden Richtlinien mit der Annotation enable-logging im Logeintrag aufgeführt. Ein Konfigurationsfehler tritt auf, wenn Sie spec.cluster.allow.delegate auf true und spec.cluster.allow.log auf false setzen.
cluster.deny	struct	Einstellungen für das Logging abgelehnter Verbindungen Feld Typ Beschreibung log bool Wenn true festgelegt ist, werden abgelehnte Verbindungen im Cluster protokolliert. Andernfalls werden abgelehnte Verbindungen nicht protokolliert. delegate bool Bei false werden alle abgelehnten Verbindungen protokolliert. Bei true werden abgelehnte Verbindungen nur dann protokolliert, wenn der Pod, in dem die Verbindung abgelehnt wurde, in einem Namespace mit der Annotation policy.network.gke.io/enable-deny-logging: "true" enthalten ist. Ein Konfigurationsfehler tritt auf, wenn Sie spec.cluster.deny.delegate auf true und spec.cluster.deny.log auf false setzen.

Auf Logs von Netzwerkrichtlinien zugreifen

Logs von Netzwerkrichtlinien werden automatisch in Cloud Logging hochgeladen. Sie können auf Logs über den Log-Explorer oder mit der Google Cloud CLI zugreifen. Sie können auch Logs an eine Senke weiterleiten.

Cloud Logging

1. Rufen Sie in der Google Cloud Console den Log-Explorer auf.

   Zum Log-Explorer

2. Klicken Sie auf Query Builder.

3. Verwenden Sie die folgende Abfrage, um alle Logs der Netzwerkrichtlinien zu finden:

   resource.type="k8s_node"
   resource.labels.location="CLUSTER_LOCATION"
   resource.labels.cluster_name="CLUSTER_NAME"
   logName="projects/PROJECT_NAME/logs/policy-action"
   

   Ersetzen Sie Folgendes:

   • CLUSTER_LOCATION ist der Compute Engine-Standort des Clusters.
   • CLUSTER_NAME ist der Name Ihres Clusters.
   • PROJECT_NAME ist der Name Ihres Google Cloud-Projekts.

Informationen zur Verwendung des Log-Explorers finden Sie unter Log-Explorer verwenden.

Sie können auch eine Abfrage mit dem Query Builder erstellen. Zum Erstellen einer Abfrage für Netzwerkrichtlinienlogs wählen Sie in der Drop-down-Liste policy-action den Eintrag policy-action aus. Wenn keine Logs verfügbar sind, wird policy-action nicht in der Drop-down-Liste angezeigt.

gcloud

Alle Netzwerkrichtlinien-Log-einträge finden:

gcloud logging read --project "PROJECT_NAME" 'resource.type="k8s_node"
    resource.labels.location="CLUSTER_LOCATION"
    resource.labels.cluster_name="CLUSTER_NAME"
    logName="projects/PROJECT_NAME/logs/policy-action"'

Ersetzen Sie Folgendes:

• PROJECT_NAME ist der Name Ihres Google Cloud-Projekts.
• CLUSTER_LOCATION ist der Compute Engine-Standort des Clusters.
• CLUSTER_NAME ist der Name Ihres Clusters.

Sie können weitere Bedingungen hinzufügen, um die Ergebnisse zu filtern. Beispiel:

• So rufen Sie Logs aus einem bestimmten Zeitraum auf:

  timestamp>="2020-06-22T06:30:51.128Z"
  timestamp<="2020-06-23T06:30:51.128Z"
  

• So rufen Sie Logs für abgelehnte Verbindungen auf:

  jsonPayload.disposition="deny"
  

• So rufen Sie Logs für ein Deployment mit dem Namen "redis" auf:

  jsonPayload.dest.pod_name=~"redis"
  jsonPayload.dest.pod_namespace="default"
  

• So rufen Sie Logs für Cluster-externe Verbindungen auf:

  jsonPayload.dest.instance != ""
  

• So rufen Sie Logs auf, die mit einer bestimmten Netzwerkrichtlinie übereinstimmen, in diesem Fall "allow-frontend-to-db":

  jsonPayload.policies.name="allow-frontend-to-db"
  jsonPayload.policies.namespace="default"
  

Wenn Sie einen Standardcluster verwenden, finden Sie die Logs der Netzwerkrichtlinien, die auf jedem Clusterknoten lokal erstellt werden, auch unter /var/log/network/policy_action.log*. Wenn die aktuelle Logdatei 10 MB erreicht, wird eine neue nummerierte Logdatei erstellt. Es werden bis zu fünf vorherige Logdateien gespeichert.

Format für Logs von Netzwerkrichtlinien

Einträge für Logs von Netzwerkrichtlinien liegen im JSON-Format vor. Dieses Format wird in der folgenden Tabelle beschrieben:

Feld	Typ	Beschreibung
connection	struct	Verbindungsinformationen: Feld Typ Beschreibung src_ip string Quell-IP-Adresse der Verbindung. src_port int Quellport der Verbindung. dest_ip string Ziel-IP-Adresse der Verbindung. dest_port int Zielport der Verbindung. protocol string Protokoll der Verbindung, entweder tcp, udp oder icmp. direction string Richtung der Verbindung, entweder ingress oder egress
src	struct	Endpunktinformationen der Quelle: Feld Typ Beschreibung pod_name string Name des Pods, wenn die Quelle ein Pod ist. pod_namespace (deprecated) string Namespace des Pods, wenn die Quelle ein Pod ist. pod_namespace wurde verworfen (verwenden Sie stattdessen namespace). namespace string Namespace des Pods, wenn die Quelle ein Pod ist. workload_name string Name der Arbeitslast, wenn die Zielarbeitslast verfügbar ist. workload_kind string Art der Arbeitslast, wenn die Quellarbeitslast verfügbar ist. instance string IP-Adresse der Quelle, wenn die Quelle kein Pod ist.
dest	struct	Endpunktinformationen des Ziels: Feld Typ Beschreibung pod_name string Name des Pods, wenn das Ziel ein Pod ist pod_namespace (deprecated) string Namespace des Pods, wenn das Ziel ein Pod ist pod_namespace wurde verworfen (verwenden Sie stattdessen namespace). namespace string Namespace des Pods, wenn das Ziel ein Pod ist workload_name string Name der Arbeitslast, wenn die Zielarbeitslast verfügbar ist. workload_kind string Art der Arbeitslast, wenn die Zielarbeitslast verfügbar ist. instance string IP-Adresse der Quelle, wenn das Ziel kein Pod ist.
disposition	string	Richtung der Verbindung, entweder allow oder deny.
policies	list of structs	Übereinstimmende Richtlinien für die erlaubten Verbindungen aus der Sicht des erzwungenen Pods. Bei Ingress-Verbindungen ist der erzwungene Pod der Ziel-Pod. Bei ausgehenden Verbindungen ist der erzwungene Pod der Quell-Pod. Es werden mehrere Richtlinien protokolliert, wenn eine Verbindung mit allen übereinstimmt. Dieses Feld ist nur in Logs von zulässigen Verbindungen enthalten. Feld Typ Beschreibung name string Name der passenden Netzwerkrichtlinie. namespace string Namespace der passenden Netzwerkrichtlinie.
count	int	Wird für die Logaggregation von abgelehnten Abfragen verwendet. Bei erlaubten Verbindungen ist der Wert immer 1.
node_name	string	Der Knoten, auf dem der Pod ausgeführt wird, der diesen Logeintrag generiert hat.
timestamp	string	Zeitpunkt des Verbindungsversuchs

Hinweis: namespace, workload_name und workload_kind sind in den folgenden Versionen verfügbar:

• 1.20.10-gke.2200 bis 1.21
• 1.21.4-gke.2300 bis 1.22
• 1.22.1-gke.1700 und höher

Definition der Verbindung

Bei verbindungsorientierten Protokollen wie TCP wird ein Log für jede zugelassene oder abgelehnte Verbindung erstellt. Bei nicht verbindungsorientierten Protokollen wie UDP und ICMP werden Pakete in zeitfensterbasierten Verbindungen gruppiert.

Richtlinienlogs für abgelehnte Verbindungen

Die Logeinträge für abgelehnte Verbindungen enthalten das Feld policies nicht da die Kubernetes Network Policy API keine expliziten Ablehnungsrichtlinien hat. Eine Verbindung wird verweigert, wenn ein Pod von einer oder mehreren Netzwerkrichtlinien abgedeckt wird, aber keine der Richtlinien die Verbindung zulässt. Dies bedeutet, dass für eine blockierte Verbindung keine Richtlinie allein verantwortlich ist.

Logaggregation für abgelehnte Verbindungen

Es ist üblich, dass ein Client versucht, eine zuvor abgelehnte Verbindung noch einmal herzustellen. Damit übermäßiges Logging vermieden wird, werden wiederholte abgelehnte Verbindungen in einem 5-Sekunden-Fenster mit dem Feld count zu einer einzigen Lognachricht zusammengefasst.

Nachfolgende abgelehnte Verbindungen werden mit einer vorherigen Lognachricht aggregiert, wenn src_ip, dest_ip, dest_port, protocol, und direction der Verbindung der ersten abgelehnten Verbindung entsprechen. Der src_port der nachfolgenden Verbindungen muss nicht übereinstimmen, da wiederholte Verbindungen von einem anderen Port stammen können. Der aggregierte Logeintrag enthält den src_prt der ersten abgelehnten Verbindung zu Beginn des Aggregationsfensters.

Beispiel für Logeinträge

Die folgende beispielhafte Netzwerkrichtlinie namens allow-green, die auf test-service angewendet wird, ermöglicht Verbindungen zu test-service von einem Pod mit dem Namen client-green. Daher lehnt diese Richtlinie den gesamten eingehenden Traffic zu test-service ab, auch vom Pod client-red.

  apiVersion: networking.k8s.io/v1
  kind: NetworkPolicy
  metadata:
    name: allow-green
    namespace: default
    annotations:
      policy.network.gke.io/enable-logging: "true"
  spec:
    podSelector:
      matchLabels:
        app: test-service
    ingress:
    - from:
      - podSelector:
          matchLabels:
            app: client-green
    policyTypes:
    - Ingress

Dieses Diagramm zeigt die Auswirkung der Richtlinie allow-green auf zwei Verbindungen zu test-service. Die Richtlinie allow-green lässt die Verbindung von client-green zu. Da keine Richtlinie die Verbindung von client-red zulässt, wird die Verbindung abgelehnt.

Das Log für die erlaubte Verbindung von client-green sieht so aus:

{
   "connection":{
      "src_ip":"10.84.0.252",
      "dest_ip":"10.84.0.165",
      "src_port":52648,
      "dest_port":8080,
      "protocol":"tcp",
      "direction":"ingress"
   },
   "disposition":"allow",
   "policies":[
      {
         "name":"allow-green",
         "namespace":"default"
      }
   ],
   "src":{
      "pod_name":"client-green-7b78d7c957-68mv4",
      "pod_namespace":"default",
      "namespace":"default",
      "workload_name":"client-green-7b78d7c957",
      "workload_kind":"ReplicaSet"
   },
   "dest":{
      "pod_name":"test-service-745c798fc9-sfd9h",
      "pod_namespace":"default",
      "namespace":"default",
      "workload_name":"test-service-745c798fc9",
      "workload_kind":"ReplicaSet"
   },
   "count":1,
   "node_name":"gke-demo-default-pool-5dad52ed-k0h1",
   "timestamp":"2020-06-16T03:10:37.993712906Z"
}

Das Log für die abgelehnte Verbindung von client-red sieht so aus:

{
   "connection":{
      "src_ip":"10.84.0.180",
      "dest_ip":"10.84.0.165",
      "src_port":39610,
      "dest_port":8080,
      "protocol":"tcp",
      "direction":"ingress"
   },
   "disposition":"deny",
   "src":{
      "pod_name":"client-red-5689846f5b-b5ccx",
      "pod_namespace":"default",
      "namespace":"default",
      "workload_name":"client-red-5689846f5b",
      "workload_kind":"ReplicaSet"
   },
   "dest":{
      "pod_name":"test-service-745c798fc9-sfd9h",
      "pod_namespace":"default",
      "namespace":"default",
      "workload_name":"test-service-745c798fc9",
      "workload_kind":"ReplicaSet"
   },
   "count":3,
   "node_name":"gke-demo-default-pool-5dad52ed-k0h1",
   "timestamp":"2020-06-15T22:38:32.189649531Z"
}

Beachten Sie, dass das Log für die abgelehnte Verbindung nicht das Feld policies enthält. Dies wird im vorherigen Abschnitt Richtlinienlogs für abgelehnte Verbindungen beschrieben.

Das Log für die abgelehnte Verbindung enthält das Feld count für aggregierte abgelehnte Verbindungen.

Probleme mit Logs von Netzwerkrichtlinien beheben

1. Suchen Sie im Objekt NetworkLogging nach Fehlerereignissen:

   kubectl describe networklogging default
   

   Wenn die Logging-Konfiguration ungültig ist, wird sie nicht wirksam und im Bereich der Ereignisse wird ein Fehler gemeldet:

   Name:         default
   Namespace:
   Labels:       addonmanager.kubernetes.io/mode=EnsureExists
   Annotations:  API Version:  networking.gke.io/v1alpha1
   Kind:         NetworkLogging
   Metadata:
     Creation Timestamp:  2020-06-20T05:54:08Z
     Generation:          8
     Resource Version:    187864
     Self Link:           /apis/networking.gke.io/v1alpha1/networkloggings/default
     UID:                 0f1ddd6e-4193-4295-9172-baa6a52aa6e6
   Spec:
     Cluster:
       Allow:
         Delegate:  true
         Log:       false
       Deny:
         Delegate:  false
         Log:       false
   Events:
     Type     Reason                 Age                From                                                               Message
     ----     ------                 ----               ----                                                               -------
     Warning  InvalidNetworkLogging  16s (x3 over 11h)  network-logging-controller, gke-anthos-default-pool-cee49209-0t09  cluster allow log action is invalid: delegate cannot be true when log is false
     Warning  InvalidNetworkLogging  16s (x3 over 11h)  network-logging-controller, gke-anthos-default-pool-cee49209-80fx  cluster allow log action is invalid: delegate cannot be true when log is false
   

2. Zur Begrenzung der für Logging genutzten CPU-Auslastung kann ein Knoten bis zu 500 Verbindungen pro Sekunde protokollieren, bevor er Logs löscht. Die Netzwerkrichtlinien für den Knoten werden weiterhin erzwungen. Sie können sehen, ob Richtlinienlogs verworfen wurden. Prüfen Sie dazu, ob mehr Fehler im Fehlerzähler angezeigt werden.

   kubectl exec ANETD_POD_NAME -n kube-system -- curl -s http://localhost:9990/metrics |grep policy_logging
   

   Ersetzen Sie ANETD_POD_NAME durch den Namen eines anetd-Pods. Prüfen Sie die einzelnen Knoten. anetd ist der Netzwerkcontroller für Dataplane V2.

Logs ohne Namen werden für Pods mit standardmäßigen Ablehnungsrichtlinien angezeigt

Aktivitäts-, Bereitschafts- und Startprüfungen erfordern, dass der Pod die von den Prüfungen hergestellten Ingress-Verbindungen von kubelet akzeptiert. Damit diese Prüfungen ordnungsgemäß funktionieren, lässt GKE unabhängig von den auf den Pod angewendeten Netzwerkrichtlinien automatisch Prüfungs-Traffic an den ausgewählten Pod zu. Dieses Verhalten kann nicht geändert werden.

Logs für Prüfungsverbindungen sehen in etwa so aus:

{
   "connection":{
      "src_ip":"10.88.1.1",
      "dest_ip":"10.88.1.4",
      "src_port":35848,
      "dest_port":15021,
      "protocol":"tcp",
      "direction":"ingress"
   },
   "disposition":"allow",
   "src":{
      "instance":"10.88.1.1"
   },
   "dest":{
      "pod_name":"testpod-745c798fc9-sfd9h",
      "pod_namespace":"default",
      "namespace":"default",
      "workload_name":"testpod-745c798fc9",
      "workload_kind":"ReplicaSet"
   },
   "count":1,
   "policies": [
     {
       "name":""
     }
    ],
   "node_name":"gke-demo-default-pool-5dad52ed-k0h1",
   "timestamp":"2021-04-01T12:42:32.1898720941Z"
}

Das Log hat folgende Merkmale:

• Der Wert von policies.name ist leer, da keine Netzwerkrichtlinie zugeordnet ist, die die Verbindung zulässt.
• Der Wert von connection.src_ip entspricht keinem Pod oder Knoten.

Nächste Schritte

• Logs mit Cloud Logging aufrufen und analysieren
• Gängige Ansätze zur Beschränkung des Traffics mithilfe von Netzwerkrichtlinien

• Arbeitslastkonnektivität mit GKE Dataplane V2 ansehen