Diese Seite wurde von der Cloud Translation API übersetzt.

Audit-Richtlinie

Autopilot Standard

In diesem Dokument wird die Audit-Logging-Richtlinie in Google Kubernetes Engine (GKE) beschrieben. In diesem Dokument wird davon ausgegangen, dass Sie mit Folgendem vertraut sind:

GKE erfasst und zeichnet Ereignisse in Ihrem Cluster auf. Mehrere Faktoren beeinflussen, welche Informationen protokolliert werden, wo diese Informationen gespeichert werden und welche Richtlinien sich auf die Inhalte Ihrer Audit-Logs auswirken.

Dieses Dokument richtet sich an Sicherheitsexperten, die Einblick in die Aktivitäten in Ihren Clustern erhalten möchten, um Sicherheitsrisiken zu erkennen, Änderungen nachzuverfolgen und Probleme zu beheben. Weitere Informationen zu gängigen Rollen und Beispielaufgaben, auf die wir in Google Cloud -Inhalten verweisen, finden Sie unter Häufig verwendete GKE-Nutzerrollen und -Aufgaben.

Informationen zum Aktivieren und Aufrufen der verschiedenen Arten von Audit-Logs sowie der erforderlichen IAM-Berechtigungen finden Sie unter Informationen zum GKE-Audit-Logging.

Übersicht über Audit-Richtlinien

In einem GKE-Cluster schreibt der Kubernetes API-Server Audit-Logeinträge in ein von GKE verwaltetes Backend. Wenn GKE Logeinträge vom Kubernetes API-Server erhält, werden diese in das Administratoraktivitätslog und das Datenzugriffslog Ihres Projekts geschrieben.

Der Inhalt des Audit-Logs Ihres Projekts hängt von zwei Richtlinien ab:

In der Audit-Richtlinie in Kubernetes ist definiert, welche Ereignisse als Logeinträge erfasst werden. Darin ist auch festgelegt, welche Daten die Logeinträge enthalten sollen.
In der GKE-Audit-Richtlinie ist angegeben, welche Einträge jeweils in das Administratoraktivitätslog und das Datenzugriffslog geschrieben werden.

Welche Audit-Logs in Ihr Datenzugriffslog geschrieben werden, hängt von der Konfiguration des Audit-Logs ab. Für Datenzugriffslogs werden die Preise für Google Cloud Observability verwendet. Administratoraktivitäts-Logs sind kostenlos. GKE unterstützt die folgenden Arten von Datenzugriffslogs.

ADMIN_READ: Vorgänge, die Metadaten zu Kubernetes-Ressourcen lesen, z. B. das Auflisten von Pods.
DATA_READ: Vorgänge, bei denen Daten in Kubernetes-Ressourcen gelesen werden, z. B. das Lesen der Logs für einen Pod.
DATA_WRITE: Vorgänge, die Daten in Kubernetes-Ressourcen schreiben, z. B. das Aktualisieren des Pod-Status.

Weitere Informationen finden Sie unter Audit-Logs zum Datenzugriff konfigurieren.

Audit-Richtlinie in Kubernetes

Der Kubernetes API-Server unterliegt einer Richtlinie, die im Flag --audit-policy-file des Befehls kube-apiserver angegeben ist.

Wenn GKE den Kubernetes API-Server startet, wird eine Audit-Richtliniendatei durch Festlegung eines Werts für das Flag --audit-policy-file bereitgestellt. Im Open-Source-Repository von Kubernetes finden Sie das Skript configure-helper.sh für die Generierung der Audit-Richtliniendatei. Den Großteil der Audit-Richtliniendatei sehen Sie direkt im Skript.

Ereignisse und Phasen

Wenn ein Nutzer oder eine Komponente eine Anfrage an den Kubernetes API-Server sendet, durchläuft die Anfrage eine oder mehrere Phasen:

Phase	Beschreibung
RequestReceived	Der Audit-Handler hat die Anfrage erhalten.
ResponseStarted	Die Antwortheader wurden ohne den Antworttext gesendet.
ResponseComplete	Der Antworttext wurde fertiggestellt und es werden keine weiteren Byte gesendet.
Panic	Die Anfrage wurde aufgrund eines internen Serverfehlers nicht abgeschlossen.

In jeder Phase einer Anfrage wird ein Ereignis generiert und gemäß einer Richtlinie verarbeitet. Die Richtlinie gibt an, ob und mit welchen Daten das Ereignis als Logeintrag erfasst werden soll.

Audit-Ebenen

Die Audit-Richtliniendatei in Kubernetes enthält eine Liste mit Regeln. Die Audit-Ebene des Ereignisses wird durch die erste Regel in der Richtliniendatei festgelegt, die mit einem Ereignis übereinstimmt.

Folgende Audit-Ebenen können durch Regeln festgelegt werden:

Ebene	Beschreibung
–	Für das Ereignis wird kein Logeintrag erstellt.
Metadaten	Ein Logeintrag wird erstellt. Metadaten werden einbezogen, während der Anfrage- und Antworttext ausgeschlossen sind.
Anfrage	Ein Logeintrag wird erstellt. Metadaten und der Anfragetext werden einbezogen, während der Antworttext ausgeschlossen ist.
RequestResponse	Ein Logeintrag wird erstellt. Metadaten sowie der Anfrage- und Antworttext werden einbezogen.

Hier ein Beispiel für eine Regel. Wenn ein Ereignis mit der Regel übereinstimmt, erstellt der Kubernetes API-Server einen Logeintrag auf der Ebene Request.

- level: Request
  userGroups: ["system:nodes"]
  verbs: ["update","patch"]
  resources:
    - group: "" # core
      resources: ["nodes/status", "pods/status"]
  omitStages:
    - "RequestReceived"

Ein Ereignis stimmt mit der Regel überein, wenn alle folgenden Bedingungen erfüllt sind:

Das Ereignis stimmt nicht mit einer vorherigen Regel in der Richtliniendatei überein.
Die Identität, die den Aufruf tätigt, befindet sich in der Nutzergruppe system:nodes.
Der Aufruf ist eine Anfrage vom Typ update oder patch.
Die Anfrage erfolgt an eine Ressource vom Typ nodes/status oder pods/status.
Das Ereignis bezieht sich nicht auf die Aufrufphase RequestReceived.

GKE-Audit-Richtlinie

Wenn GKE Logeinträge vom Kubernetes API-Server erhält, wird anhand der eigenen Richtlinie ermittelt, welche Einträge in das Administratoraktivitätslog bzw. in das Datenzugriffslog Ihres Projekts geschrieben werden.

In den meisten Fällen werden in GKE die folgenden Regeln auf Logeinträge vom Kubernetes API-Server angewendet:

Einträge, die Anfragen vom Typ create, delete oder update darstellen, werden in das Administratoraktivitätslog geschrieben.
Einträge, die Anfragen vom Typ get, list oder updateStatus darstellen, werden in das Datenzugriffslog geschrieben.

Informationen zur Preisgestaltung und zu den Arten von Logs, die standardmäßig aktiviert sind, finden Sie unter Logging-Details.

Kubernetes-Audit-Richtliniendatei für GKE-Cluster

In den ersten Regeln der Kubernetes-Audit-Richtliniendatei für GKE-Cluster ist angegeben, welche Ereignisse nicht geloggt werden sollen. Die folgende Regel besagt beispielsweise, dass Anfragen vom Typ get von kubelet an eine Ressource vom Typ nodes oder nodes/status nicht geloggt werden sollen. Wie bereits erwähnt, werden übereinstimmende Ereignisse auf der Ebene None nicht geloggt.

- level: None
  users: ["kubelet"] # legacy kubelet identity
  verbs: ["get"]
  resources:
    - group: "" # core
    resources: ["nodes", "nodes/status"]

Der Liste der level: None-Regeln folgt in der Richtliniendatei eine Liste mit Regeln, bei denen es sich um Sonderfälle handelt. Dies ist zum Beispiel eine Sonderfallregel, mit der bestimmte Anfragen auf der Ebene Metadata geloggt werden:

- level: Metadata
    resources:
      - group: "" # core
        resources: ["secrets", "configmaps"]
      - group: authentication.k8s.io
        resources: ["tokenreviews"]
    omitStages:
      - "RequestReceived"

Ein Ereignis stimmt mit der Regel überein, wenn alle folgenden Bedingungen erfüllt sind:

Das Ereignis stimmt nicht mit einer vorherigen Regel in der Richtliniendatei überein.
Die Anfrage bezieht sich auf eine Ressource vom Typ secrets, configmaps oder tokenreviews.
Das Ereignis bezieht sich nicht auf die Aufrufphase RequestReceived.

Der Liste mit den Sonderfallregeln in der Richtliniendatei folgen einige allgemeine Regeln. Ersetzen Sie den Wert known_apis durch ${known_apis}, damit die allgemeinen Regeln im Skript angezeigt werden. Sie erhalten daraufhin eine ähnliche wie die folgende Regel:

- level: Request
  verbs: ["get", "list", "watch"]
  resources:
    - group: "" # core
    - group: "admissionregistration.k8s.io"
    - group: "apiextensions.k8s.io"
    - group: "apiregistration.k8s.io"
    - group: "apps"
    - group: "authentication.k8s.io"
    - group: "authorization.k8s.io"
    - group: "autoscaling"
    - group: "batch"
    - group: "certificates.k8s.io"
    - group: "extensions"
    - group: "metrics.k8s.io"
    - group: "networking.k8s.io"
    - group: "policy"
    - group: "rbac.authorization.k8s.io"
    - group: "settings.k8s.io"
    - group: "storage.k8s.io"
  omitStages:
    - "RequestReceived"

Die Regel gilt für Ereignisse, die mit keiner vorangegangenen Regel in der Richtliniendatei übereinstimmen und sich nicht in der Phase RequestReceived befinden. Die Regel besagt, dass Anfragen vom Typ get, list und watch an eine Ressource in einer der aufgeführten Gruppen auf der Ebene Request geloggt werden sollen.

Die nächste Regel in der Richtliniendatei sieht in etwa so aus:

- level: RequestResponse
  resources:
    - group: "" # core
    - group: "admissionregistration.k8s.io"
    - group: "apiextensions.k8s.io"
    - group: "apiregistration.k8s.io"
    - group: "apps"
    - group: "authentication.k8s.io"
    - group: "authorization.k8s.io"
    - group: "autoscaling"
    - group: "batch"
    - group: "certificates.k8s.io"
    - group: "extensions"
    - group: "metrics.k8s.io"
    - group: "networking.k8s.io"
    - group: "policy"
    - group: "rbac.authorization.k8s.io"
    - group: "settings.k8s.io"
    - group: "storage.k8s.io"
  omitStages:
    - "RequestReceived"

Die Regel gilt für Ereignisse, die mit keiner vorangegangenen Regel in der Richtliniendatei übereinstimmen und sich nicht in der Phase RequestReceived befinden. Die Regel gilt nicht für die Leseanfragen get, list und watch. Stattdessen wird die Regel auf Schreibanfragen wie create, update und delete angewendet. Die Regel besagt, dass Schreibanfragen auf der Ebene RequestResponse geloggt werden sollen.

Zusammenfassung der Kubernetes-Audit-Richtlinie für GKE-Cluster

In der folgenden Liste wird die Kubernetes-Audit-Richtlinie für GKE-Cluster zusammengefasst:

Generell werden Schreibanfragen wie create, update und delete auf der Ebene RequestResponse geloggt.
Generell werden Schreibanfragen wie get, list und watch auf der Ebene Metadata geloggt.
Manche Ereignisse werden als Sonderfälle behandelt. Eine aktuelle Liste der als Sonderfälle geltenden Anfragen finden Sie im Richtlinienskript. Zu den Sonderfällen gehören:
- Update- und Patch-Anfragen von kubelet, system:node-problem-detector oder system:serviceaccount:kube-system:node-problem-detector an eine Ressource vom Typ nodes/status oder pods/status werden auf Anfrageebene geloggt.
- Update- und Patch-Anfragen von einer Identität in der Gruppe system:nodes an eine Ressource vom Typ nodes/status oder pods/status werden auf der Anfrageebene geloggt.
- Anfragen vom Typ deletecollection von system:serviceaccount:kube-system:namespace-controller werden auf der Anfrageebene geloggt.
- Anfragen an eine Ressource vom Typ secrets Ressource, configmaps oder tokenreviews werden auf der Metadatenebene geloggt.
Bestimmte Anfragen werden gar nicht geloggt. Eine aktuelle Liste der nicht geloggten Anfragen finden Sie bei den Regeln level: None im Richtlinienskript. Die folgenden Anfragen werden nicht protokolliert:
- Anfragen von system:kube-proxy zum Beobachten einer Ressource vom Typ endpoints, services oder services/status.
- GET-Anfragen von system:unsecured an eine Ressource vom Typ configmaps im Namespace kube-system.
- GET-Anfragen von kubelet an eine Ressource vom Typ nodes oder nodes/status.
- GET-Anfragen von einer Identität in der Gruppe system:nodes an eine Ressource vom Typ nodes oder nodes/status.
- GET- und Update-Anfragen von system:kube-controller-manager, system:kube-scheduler oder system:serviceaccount:endpoint-controller an eine Ressource vom Typ endpoints im Namespace kube-system.
- GET-Anfragen von system:apiserver an eine Ressource vom Typ namespaces , namespaces/status oder namespaces/finalize.
- GET- und Auflistungsanfragen von system:kube-controller-manager an eine Ressource in der Gruppe metrics.k8s.io.
- Anfragen an URLs, die mit /healthz*, /version oder /swagger* übereinstimmen.