Linux-Audit-Logs für GKE-Knoten aktivieren

Auf dieser Seite wird erläutert, wie ausführliche Audit-Logs des Betriebssystems auf Google Kubernetes Engine-Knoten mit Container-Optimized OS aktiviert werden. Auf dieser Seite wird auch erläutert, wie Sie einen fluent-bit-Logging-Agent konfigurieren, um Logs an Cloud Logging zu senden. Wenn Sie ausführliche Logs aktivieren, erhalten Sie wertvolle Informationen zum Status Ihres Clusters und Ihrer Arbeitslasten, z. B. Fehlermeldungen, Anmeldeversuche und binäre Ausführungen. Sie können diese Informationen verwenden, um Probleme zu beheben oder Sicherheitsvorfälle zu untersuchen.

Das Aktivieren des Linux-Audit-Loggings wird in GKE Autopilot-Clustern nicht unterstützt, da Google die Knoten und zugrunde liegende virtuelle Maschinen (VMs) verwaltet.

Diese Seite richtet sich an Sicherheitsexperten, die Sicherheitslogs prüfen und analysieren. Anhand dieser Informationen können Sie die Anforderungen und Einschränkungen von ausführlichen Betriebssystemlogs nachvollziehen und Ihre Implementierung entsprechend anpassen, wenn Sie sie auf Ihren GKE-Knoten aktivieren. 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.

Machen Sie sich vor dem Lesen dieser Seite mit Audit-Logs für Linux-Betriebssysteme vertraut.

Das Audit-Logging des Betriebssystems unterscheidet sich von Cloud-Audit-Logs und Kubernetes-Audit-Logs.

Übersicht

Zum Erfassen der Logs von jedem Knoten in einem Cluster verwenden Sie ein DaemonSet, das genau einen Pod auf jedem Clusterknoten ausführt, auf dem das DaemonSet geplant werden kann. Dieser Pod konfiguriert den Logging-Daemon auditd auf dem Host und konfiguriert den Logging-Agent so, dass er die Logs an Logging oder einen anderen Service zur Logaufnahme sendet.

Definitionsgemäß erfolgt das Auditing nach einem Ereignis und ist eine retrospektive Sicherheitsmaßnahme. Auditd-Logs alleine reichen wahrscheinlich nicht aus, um die Forensik für Ihren Cluster durchzuführen. Sie überlegen, wie Sie das Auditd-Logging als Teil Ihrer Gesamtsicherheitsstrategie optimal einsetzen können.

Beschränkungen

Die auf dieser Seite beschriebenen Logging-Mechanismen funktionieren nur auf Knoten, auf denen Container-Optimized OS in GKE Standard-Clustern ausgeführt wird.

Funktionsweise des Logging-DaemonSets

In diesem Abschnitt erfahren Sie, wie das Beispiel-Logging-DaemonSet funktioniert, damit Sie es entsprechend Ihren Anforderungen konfigurieren können. Im nächsten Abschnitt wird erläutert, wie das DaemonSet bereitgestellt wird.

Das Beispielmanifest definiert ein DaemonSet, eine ConfigMap und einen Namespace, um sie zu enthalten.

Das DaemonSet stellt auf jedem Knoten im Cluster einen Pod bereit. Der Pod enthält zwei Container. Der erste ist ein init-Container, der den systemd-Dienst "cloud-audit-setup" startet, der auf Container-Optimized OS-Knoten verfügbar ist. Der zweite Container, cos-auditd-fluent-bit, enthält eine Instanz vonfluent-bit, die dafür konfiguriert ist, die Linux-Audit-Logs aus dem Knotenjournal zu erfassen und nach Cloud Logging zu exportieren.

Das Beispiel-Logging-DaemonSet erfasst die folgenden Ereignisse:

  • auditd-Änderungen an der Betriebssystemkonfiguration
  • AppArmor-Berechtigungsprüfungen
  • execve()-, socket()-, setsockopt()- und mmap()-Ausführungen
  • Netzwerkverbindungen
  • Nutzeranmeldungen
  • SSH-Sitzung und alle anderen TTYs (einschließlich kubectl exec -t-Sitzungen)

Logging-DaemonSet konfigurieren

Sie konfigurieren das Logging-DaemonSet mithilfe einer ConfigMap, cos-auditd-fluent-bit-config. In diesem Beispiel werden Audit-Logs an Logging gesendet. Sie können es jedoch so konfigurieren, dass Logs an andere Ziele gesendet werden.

Das von auditd erzeugte Logvolumen kann sehr groß sein und zusätzliche Kosten verursachen, da es Systemressourcen verbraucht und mehr Logs als die standardmäßige Logging-Konfiguration sendet. Sie können Filter einrichten, um das Logvolumen zu verwalten:

Logging-DaemonSet bereitstellen

  1. Sie können einen vorhandenen Cluster verwenden oder einen neuen erstellen.

  2. Laden Sie die Beispielmanifeste herunter:

    curl https://raw.githubusercontent.com/GoogleCloudPlatform/k8s-node-tools/master/troubleshooting/os-audit/cos-auditd-logging.yaml > cos-auditd-logging.yaml

  3. Bearbeiten Sie die Beispielmanifeste entsprechend Ihren Anforderungen. Im vorherigen Abschnitt finden Sie genauere Informationen zur Funktionsweise des DaemonSets. Das fluent-bit-Bild in diesem Beispielmanifest dient nur zur Veranschaulichung. Es empfiehlt sich, das Bild durch ein Bild aus einer kontrollierten Quelle mit SHA‑256-Digest zu ersetzen.

  4. Initialisieren Sie gemeinsame Variablen:

    export CLUSTER_NAME=CLUSTER_NAME
export CLUSTER_LOCATION=COMPUTE_REGION

    Dabei gilt:

    • CLUSTER_NAME: Der Name Ihres Clusters.
    • COMPUTE_REGION: die Compute Engine-Region für den Cluster. Verwenden Sie für zonale Cluster stattdessen die Zone.

  5. Stellen Sie das Logging-Namespace, -DaemonSet und -ConfigMap bereit:

    envsubst '$CLUSTER_NAME,$CLUSTER_LOCATION' < cos-auditd-logging.yaml \
| kubectl apply -f -

  6. Prüfen Sie, ob die Logging-Pods gestartet wurden. Wenn Sie in Ihren Manifesten einen anderen Namespace definiert haben, ersetzen Sie cos-auditd durch den Namen des von Ihnen verwendeten Namespace.

    kubectl get pods --namespace=cos-auditd

    Wenn die Pods ausgeführt werden, sieht die Ausgabe etwa so aus:

    NAME                                             READY   STATUS    RESTARTS   AGE
cos-auditd-logging-g5sbq                         1/1     Running   0          27s
cos-auditd-logging-l5p8m                         1/1     Running   0          27s
cos-auditd-logging-tgwz6                         1/1     Running   0          27s

    Je ein Pod wird auf jedem Knoten im Cluster bereitgestellt. In diesem Fall verfügt der Cluster über drei Knoten.

  7. Sie können jetzt auf die Audit-Logs in Logging zugreifen. Filtern Sie im Log-Explorer die Ergebnisse mithilfe der folgenden Abfrage:

    LOG_ID("linux-auditd")
resource.labels.cluster_name = "CLUSTER_NAME"
resource.labels.location = "COMPUTE_REGION"

    Alternativ können Sie die gcloud CLI verwenden (verwenden Sie --limit, da die Ergebnismenge sehr groß sein kann):

    gcloud logging read --limit=100 "LOG_ID("linux-auditd") AND resource.labels.cluster_name = "${CLUSTER_NAME}" AND resource.labels.location = "${CLUSTER_LOCATION}""

Logs exportieren

Informationen zum Weiterleiten Ihrer Logs an unterstützte Ziele finden Sie unter Senken konfigurieren und verwalten.

Logs deaktivieren

Wenn Sie das auditd-Logging auf Ihren Knoten deaktivieren möchten, löschen Sie das Logging-DaemonSet und stellen Sie dann das cos-auditd-logging-disable-DaemonSet bereit, um die Änderungen am systemd-Dienst auf jedem Knoten rückgängig zu machen. Nachdem Sie dieses DaemonSet bereitgestellt haben, können Sie die auditd-Protokollierung nur aktivieren, wenn die Knoten neu erstellt werden.

  1. Löschen Sie das ursprüngliche Logging-DaemonSet und die zugehörigen Ressourcen:

    kubectl delete daemonset cos-auditd-logging -n cos-auditd
kubectl delete configmap fluent-bit-config -n cos-auditd
# The namespace will be deleted by the cleanup daemonset's namespace definition

  2. Wenden Sie das Bereinigungs-DaemonSet cos-auditd-logging-disable an:

    kubectl apply -f 'https://raw.githubusercontent.com/GoogleCloudPlatform/k8s-node-tools/master/troubleshooting/os-audit/cos-auditd-logging-disable.yaml'

  3. Prüfen Sie, ob die cleanup-auditd-Pods auf allen Knoten ausgeführt werden:

    kubectl get pods -n cos-auditd -l name=cleanup-auditd -w

    Warten Sie, bis für alle Pods Running angezeigt wird.

  4. Nachdem die Bereinigungs-Pods ausgeführt wurden, prüfen Sie, ob keine neuen linux-auditd-Logs generiert werden, indem Sie die Abfragen aus dem Abschnitt Logging-DaemonSet bereitstellen ausführen. Sie können beispielsweise den folgenden gcloud CLI-Befehl verwenden:

    gcloud logging read --limit=10 --freshness="5m" \
  "LOG_ID(\"linux-auditd\") AND \
  resource.labels.cluster_name = \"${CLUSTER_NAME}\" AND \
  resource.labels.location = \"${CLUSTER_LOCATION}\""

    Mit diesem Befehl werden die Protokolle der letzten fünf Minuten geprüft. Wenn die Bereinigung erfolgreich war, ist die Ausgabe leer.

    Wenn Sie den Cloud Explorer mit demselben Filter verwenden, sollten nach dem Bereinigungszeitpunkt keine neuen Logeinträge mehr angezeigt werden.

  5. Löschen Sie das Bereinigungs-Daemonset und den Namespace:

    kubectl delete -f cleanup-auditd-daemonset.yaml

    Mit diesem Befehl werden sowohl das DaemonSet als auch der cos-auditd-Namespace gelöscht.

Nächste Schritte