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 die Operations Suite von Google Cloud gesendet werden.
Das Audit-Logging des Betriebssystems unterscheidet sich von Cloud-Audit-Logs und Kubernetes-Audit-Logs.
Übersicht
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 Stackdriver 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 fluentd-gcp-cos-auditd
ist für den Logging-Agent der Operations-Suite von Google Cloud vorgesehen, eine Anwendung, die auf fluentd beruht.
Das Beispiel-Logging-DaemonSet erfasst die folgenden Ereignisse:
auditd
-Änderungen an der Betriebssystemkonfiguration- AppArmor-Berechtigungsprüfungen
execve()
-,socket()
-,setsockopt()
- undmmap()
-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 die Operations-Suite von Google Cloud gesendet. Sie können es jedoch so konfigurieren, dass Logs an Ziele außerhalb der Operations-Suite von Google Cloud 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:
- In der ConfigMap
fluentd-gcp-config-cos-auditd
können Sie Filter einrichten, sodass bestimmte Daten nicht erfasst werden. Weitere Informationen finden Sie in dieser Anleitung zum Anpassen des Loggings der Operations-Suite von Google Cloud in GKE und zum Konfigurieren des Logging-Agents der Operations-Suite von Google Cloud. - Sie können die Operations-Suite von Google Cloud auch so konfigurieren, dass eingehende Logs gefiltert werden. Weitere Informationen finden Sie in den Logausschlüssen für die Operations-Suite von Google Cloud.
Logging-DaemonSet bereitstellen
Sie können einen vorhandenen Cluster verwenden oder einen neuen erstellen.
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
Bearbeiten Sie die Beispielmanifeste entsprechend Ihren Anforderungen. Im vorherigen Abschnitt finden Sie genauere Informationen zur Funktionsweise des DaemonSets.
Stellen Sie das Logging-DaemonSet und ConfigMap bereit:
kubectl apply -f cos-auditd-logging.yaml
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.
Sie können jetzt in der Operations-Suite von Google Cloud auf die Audit-Logs zugreifen. Filtern Sie in der Loganzeige die Ergebnisse nach VM-Instanz.
Export von Logs
Mehr zum Exportieren Ihrer Logs erfahren Sie auf den folgenden Seiten:
- Informationen zur Verwendung der Loganzeige finden Sie unter Logs exportieren.
- Informationen zur Verwendung der Cloud Logging API finden Sie unter Logs in der API exportieren.
- Wie Sie das Befehlszeilentool verwenden, wird unter gcloud logging erläutert.
Clean-up
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.
Löschen Sie das DaemonSet, die ConfigMap und deren Namespace aus dem Cluster:
kubectl delete -f cos-auditd-logging.yaml
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
- Sehen Sie sich Cloud Forensics 101 an, um mit der Forensik in der Cloud zu beginnen.
- Weitere Informationen finden Sie unter Kubernetes-Audit-Logging und Audit-Richtlinien.
- Weitere Informationen finden Sie in der Übersicht zur Kubernetes Engine-Sicherheit.
- Weitere Informationen zu Cloud-Audit-Logs