Überblick
Anthos-Cluster auf VMware (GKE On-Prem) verwenden Kubernetes-Audit-Logging, das eine chronologische Aufzeichnung der Aufrufe an den Kubernetes API-Server eines Clusters speichert. Audit-Logs sind nützlich, um verdächtige API-Anfragen zu untersuchen und Statistiken zu erfassen.
Sie können einen Cluster so konfigurieren, dass Audit-Logs auf ein Laufwerk oder in Cloud-Audit-Logs in einem Google Cloud-Projekt geschrieben werden. Das Schreiben in Cloud-Audit-Logs hat mehrere Vorteile gegenüber dem Schreiben auf Laufwerke oder sogar dem Erfassen von Logs in einem lokalen Logging-System:
- Audit-Logs für alle Anthos-Cluster können zentralisiert werden.
- In Cloud-Audit-Logs geschriebene Logeinträge sind unveränderlich.
- Cloud-Audit-Logeinträge werden 400 Tage lang aufbewahrt.
- Cloud-Audit-Logs sind im Preis von Anthos enthalten.
Audit-Logging auf Laufwerken
Standardmäßig werden Audit-Logs in einen nichtflüchtigen Speicher geschrieben, sodass VM-Neustarts und -Upgrades nicht zum Verschwinden der Logs führen. Bei Anthos-Clustern in VMware werden bis zu 12 GB Audit-Logeinträge aufbewahrt.
Cloud-Audit-Logs
Wenn Sie Cloud-Audit-Logs für einen Cluster aktivieren, werden Einträge des Audit-Logs zur Administratoraktivität vom Kubernetes API-Server des Clusters mithilfe des Google Cloud-Projekts, das Sie im Feld cloudAuditLogging.projectID
der Clusterkonfigurationsdatei angeben, an Google Cloud gesendet.
Dieses Google Cloud-Projekt wird als Audit-Logging-Projekt bezeichnet.
Ihr Audit-Logging-Projekt muss mit Ihrem Verbindungsprojekt übereinstimmen.
Wenn Sie Cloud-Audit-Logs aktivieren, deaktiviert Anthos-Cluster auf VMware laufwerksbasiertes Audit-Logging.
Für das Zwischenspeichern und Schreiben von Logeinträgen in Cloud-Audit-Logs stellt Anthos-Cluster in VMware einen audit-proxy
-Pod im Administratorcluster bereit.
Diese Komponente ist auch als Sidecar-Container in Nutzerclustern verfügbar.
Beschränkungen
Für die aktuelle Version von Cloud-Audit-Logs für Anthos-Cluster auf VMware gelten verschiedene Einschränkungen:
Das Datenzugriffs-Logging (get, list, watch-Anfragen) wird nicht unterstützt.
Das Ändern der Audit-Richtlinie von Kubernetes wird nicht unterstützt.
Cloud-Audit-Logs sind gegenüber erweiterten Netzwerkausfällen nicht resilient. Wenn die Logeinträge nicht in Google Cloud exportiert werden können, werden sie in einem 10-GB-Zwischenspeicher im Cache gespeichert. Wenn dieser Zwischenspeicher voll ist, werden die nachfolgenden Einträge gelöscht.
Anthos Audit API aktivieren
Aktivieren Sie die Anthos Audit API in Ihrem Audit-Logging-Projekt.
Dienstkonto für Cloud-Audit-Logs erstellen
Sie haben bereits ein oder mehrere Dienstkonten, die Sie für die Verwendung mit Anthos-Cluster auf VMware erstellt haben. Für dieses Feature müssen Sie ein zusätzliches Dienstkonto erstellen, das als Audit-Logging-Dienstkonto bezeichnet wird.
Erstellen Sie Ihr Audit-Logging-Dienstkonto:
gcloud iam service-accounts create audit-logging-service-account
Erstellen Sie eine JSON-Schlüsseldatei für Ihr Cloud-Audit-Log-Dienstkonto:
gcloud iam service-accounts keys create audit-logging-key.json \ --iam-account AUDIT_LOGGING_SERVICE_ACCOUNT_EMAIL
Dabei ist AUDIT_LOGGING_SERVICE_ACCOUNT_EMAIL die E-Mail-Adresse Ihres Dienstkontos.
Speichern Sie
audit-logging-key.json
auf der Administrator-Workstation am selben Speicherort wie Ihre anderen Dienstkontoschlüssel.
Administratorcluster mit aktivierten Cloud-Audit-Logs erstellen
Sie können Cloud-Audit-Logs nur dann für einen Administratorcluster aktivieren, wenn Sie den Administratorcluster erstellen. Sie können einen vorhandenen Administratorcluster nicht ändern, um Cloud-Audit-Logs zu aktivieren.
Weitere Informationen finden Sie unter Administratorcluster erstellen.
Füllen Sie in der Konfigurationsdatei für den Administratorcluster den Abschnitt
cloudAuditLogging
aus.Legen Sie für
cloudAuditLogging.projectID
die ID Ihres Audit-Logging-Projekts fest.Legen Sie für
cloudAuditLogging.clusterLocation
eine Google Cloud-Region fest, in der Audit-Logs gespeichert werden sollen. Wählen Sie zum Verbessern der Latenz eine Region in der Nähe Ihres lokalen Rechenzentrums aus.Legen Sie
cloudAuditLogging.serviceAccountKeyPath
auf den Pfad der JSON-Schlüsseldatei für Ihr Audit-Logging-Dienstkonto fest.
Beispiel:
cloudAuditLogging: projectID: "my-project" clusterLocation: "us-west1" serviceAccountKeyPath: "/my-key-folder/audit-logging-key.json"
Setzen Sie die Clustererstellung wie gewohnt fort.
Nutzercluster mit aktivierten Cloud-Audit-Logs erstellen
Weitere Informationen finden Sie unter Nutzercluster erstellen.
Füllen Sie in der Nutzercluster-Konfigurationsdatei den Abschnitt
cloudAuditLogging
aus.Legen Sie für
cloudAuditLogging.projectID
die ID Ihres Audit-Logging-Projekts fest.Legen Sie für
cloudAuditLogging.clusterLocation
eine Google Cloud-Region fest, in der Audit-Logs gespeichert werden sollen. Wählen Sie zum Verbessern der Latenz eine Region in der Nähe Ihres lokalen Rechenzentrums aus.Legen Sie für
cloudAuditLogging.serviceAccounKeyPath
den Pfad der JSON-Schlüsseldatei für Ihr Cloud-Audit-Log-Dienstkonto fest.Prüfen Sie, ob der Abschnitt
gkeConnect
ausgefüllt ist undgkeConnect.projectID
mitcloudAuditLogging.projectID
übereinstimmt.
Beispiel:
gkeConnect: projectID: "my-project" registerServiceAccountKeyPath: "/my-key-fokder/connect-register-key.json" cloudAuditLogging: projectID: "my-project" clusterLocation: "us-west1" serviceAccountKeyPath: "/my-key-folder/audit-logging-key.json"
Setzen Sie die Clustererstellung wie gewohnt fort.
Cloud-Audit-Logs für einen vorhandenen Nutzercluster aktivieren
Cloud-Audit-Logs können nur in dem Google Cloud-Projekt aktiviert werden, in dem der Nutzercluster registriert ist.
Wenn ein vorhandener Nutzercluster nicht registriert ist, registrieren Sie ihn anhand der folgenden Schritte, bevor Sie Cloud-Audit-Logs aktivieren:
Fügen Sie der Nutzercluster-Konfigurationsdatei den Abschnitt
gkeConnect
hinzu. Beispiel:gkeConnect: projectID: "my-project" registerServiceAccountKeyPath: "/my-key-fokder/connect-register-key.json"
Aktualisieren Sie den Cluster:
gkectl update cluster --config USER_CLUSTER_CONFIG --kubeconfig ADMIN_CLUSTER_KUBECONFIG
Nach der Registrierung des Nutzerclusters führen Sie die folgenden Schritte aus, um Cloud-Audit-Logs zu aktivieren:
Füllen Sie den Abschnitt
cloudAuditLogging
in der Nutzercluster-Konfigurationsdatei aus. Weitere Informationen zu den einzelnen Feldern finden Sie unter Nutzercluster mit aktivierten Cloud-Audit-Logs erstellen. DieprojectID
im AbschnittcloudAuditLogging
muss mit der ID im AbschnittgkeConnect
übereinstimmen.Aktualisieren Sie den Cluster:
gkectl update cluster --config USER_CLUSTER_CONFIG --kubeconfig ADMIN_CLUSTER_KUBECONFIG
Cloud-Audit-Logs für einen vorhandenen Nutzercluster deaktivieren
Löschen Sie in der Nutzercluster-Konfigurationsdatei den Abschnitt
cloudAuditLogging
.Aktualisieren Sie den Nutzercluster:
gkectl update cluster --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] --config [USER_CLUSTER_CONFIG]
Auf Audit-Logs zugreifen
Audit-Logging auf Laufwerken
Sehen Sie sich die Kubernetes-API-Server an, die in Ihrem Administratorcluster ausgeführt werden, sowie alle zugehörigen Nutzercluster:
kubectl --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] get pods --all-namespaces -l component=kube-apiserver
Dabei ist [ADMIN_CLUSTER_KUBECONFIG] die kubeconfig-Datei Ihres Administratorclusters.
Laden Sie die Audit-Logs des API-Servers herunter:
kubectl cp -n NAMESPACE APISERVER_POD_NAME:/var/log/kube-audit/kube-apiserver-audit.log /tmp/kubeaudit.log
Mit diesem Befehl wird die neueste Logdatei abgerufen, die bis zu 1 GB Daten für den Administratorcluster und bis zu 850 GB für Nutzercluster enthalten kann.
Die Audit-Logs für den Administratorcluster finden Sie auch auf den Knoten der Steuerungsebene unter
/var/log/kube-audit/kube-apiserver-audit.log
. Die Audit-Logs für den Nutzercluster befinden sich inPersistentVolumeClaim
mit dem Namenkube-audit-kube-apiserver-0
. Sie können auf diese Daten innerhalb Ihrer eigenen Pods übervolume
-Einträge wie den folgenden zugreifen:
volumes: - name: kube-audit hostPath: path: /var/log/kube-audit type: ""
volumes: - name: kube-audit persistentVolumeClaim: claimName: kube-audit-kube-apiserver-0 readOnly: true
Um Ihren Pod auf dem entsprechenden Administratorclusterknoten (und nur auf diesem Knoten) zu planen, müssen Sie Ihrer Pod-Spezifikation die Abschnitte nodeSelector
und tolerations
so hinzufügen:
spec: nodeSelector: node-role.kubernetes.io/master: '' tolerations: - key: node-role.kubernetes.io/master value: "" effect: NoSchedule
Verwenden Sie für den Nutzercluster diese nodeSelector
:
spec: nodeSelector: kubernetes.googleapis.com/cluster-name: USER_CLUSTER_NAME
Ältere Audit-Datensätze werden in separaten Dateien gespeichert. So rufen Sie diese Dateien auf:
kubectl exec -n NAMESPACE APISERVER_POD_NAME -- ls /var/log/kube-audit -la
Der Dateiname jedes Audit-Logs enthält einen Zeitstempel, der angibt, wann die Datei rotiert wurde. Eine Datei enthält Audit-Logs bis zu diesem Zeitpunkt.
Cloud-Audit-Logs
Console
Rufen Sie in der Google Cloud Console im Menü Logging die Seite Logs auf.
Klicken Sie oberhalb der gerade erwähnten Drop-down-Menüs im Feld Nach Label oder Textsuche filtern auf den Abwärtspfeil, um das Drop-down-Menü zu öffnen. Wählen Sie im Menü den Eintrag In erweiterten Filter umwandeln aus.
Füllen Sie das Textfeld mit dem folgenden Filter aus:
resource.type="k8s_cluster" logName="projects/PROJECT_ID/logs/externalaudit.googleapis.com%2Factivity" protoPayload.serviceName="anthosgke.googleapis.com"
Klicken Sie auf Filter senden, um alle Audit-Logs von Anthos-Clustern auf VMware-Clustern anzuzeigen, die für die Anmeldung in diesem Projekt konfiguriert wurden.
gcloud
Listen Sie die ersten beiden Logeinträge im Administratoraktivitätslog des Projekts auf, die sich auf den Ressourcentyp k8s_cluster
beziehen:
gcloud logging read \ 'logName="projects/PROJECT_ID/logs/externalaudit.googleapis.com%2Factivity" \ AND resource.type="k8s_cluster" \ AND protoPayload.serviceName="anthosgke.googleapis.com" ' \ --limit 2 \ --freshness 300d
Dabei ist PROJECT_ID Ihre Projekt-ID.
Es werden zwei Logeinträge ausgegeben. Beachten Sie, dass das Feld logName
für jeden Logeintrag den Wert projects/PROJECT_ID/logs/externalaudit.googleapis.com%2Factivity
hat und protoPayload.serviceName
gleich anthosgke.googleapis.com
ist.
Audit-Richtlinie
Das Verhalten von Cloud-Audit-Logs wird durch eine statisch konfigurierte Audit-Logging-Richtlinie von Kubernetes bestimmt. Das Ändern dieser Richtlinie wird derzeit nicht unterstützt, wird aber in einer zukünftigen Version möglich sein.