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 den Logging-Agent so konfigurieren, dass Logs an Cloud Logging gesendet werden.

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

Überblick

Betriebssystemlogs auf den Knoten liefern wertvolle Informationen über den Status Ihres Clusters und der 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.

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 nachträgliche 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 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-Service "cloud-audit-setup" startet. Der zweite Container namens fluentd-gcp-cos-auditd gehört zum Logging-Agent, einer auf fluentd basierenden Anwendung.

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, fluentd-gcp-config-cos-auditd. 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/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.

  4. Stellen Sie das Logging-DaemonSet und ConfigMap bereit:

    kubectl apply -f cos-auditd-logging.yaml

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

  6. Sie können jetzt auf die Audit-Logs in Logging zugreifen. Filtern Sie im Log-Explorer die Ergebnisse nach VM-Instanz.

Export von Logs

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

Bereinigen

Wenn Sie das auditd-Logging deaktivieren möchten, löschen Sie das Logging-DaemonSet und starten die Knoten neu. Die Audit-Konfiguration ist gesperrt, sobald sie aktiviert ist. Sie kann nur durch erneutes Erstellen des Knotens geändert werden.

  1. Löschen Sie das DaemonSet, die ConfigMap und deren Namespace aus dem Cluster:

    kubectl delete -f cos-auditd-logging.yaml

  2. Starten Sie die Knoten Ihres Clusters neu. Rufen Sie zuerst die Instanzgruppe ab, zu der sie gehören:

    instance_group=$(gcloud compute instance-groups managed list \
                    --format="value(name)" \
                    --filter=${CLUSTER_NAME})

    Rufen Sie dann die Instanzen selbst ab:

    instances=$(gcloud compute instance-groups managed list-instances ${instance_group} \
               --format="csv(instance)[no-heading][terminator=',']")

    Erstellen Sie abschließend die Instanzen neu:

    gcloud compute instance-groups managed recreate-instances ${instance_group} \
   --instances=${instances}

Nächste Schritte