Übersicht
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.
Vor Anthos 1.2 schreibt Anthos-Cluster in VMware Audit-Logs nur auf das Laufwerk. Mit Anthos 1.2 wird eine Alphafeature eingeführt, mit dem Audit-Logs in Cloud-Audit-Logs in einem Google Cloud-Projekt geschrieben werden können. 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.
Sie können Anthos-Cluster in VMware so konfigurieren, dass Logs auf das Laufwerk oder in Cloud-Audit-Logs geschrieben werden.
Audit-Logging auf Laufwerken
Standardmäßig werden Audit-Logs in GKE On-Prem in einen nichtflüchtigen Speicher geschrieben, damit 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 Cloud-Audit-Logs aktiviert sind, werden die Audit-Logeinträge zu Administratoraktivitäten von allen Kubernetes-API-Servern unter Verwendung des Projekts und der Position, die Sie beim Erstellen eines Nutzerclusters angeben, an Google Cloud gesendet. Wenn Sie Cloud-Audit-Logs aktivieren, deaktiviert GKE On-Prem das Audit-Logging auf Laufwerken.
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.
Dieser Pod ist auch als Sidecar-Container in Nutzerclustern verfügbar.
Beschränkungen
Cloud-Audit-Logs für GKE On-Prem sind ein Alphafeature. Diese Alphaversion unterliegt einigen Beschränkungen:
Datenzugriffs-Logging wird nicht unterstützt.
Das Ändern der Audit-Richtlinie von Kubernetes wird nicht unterstützt.
Cloud-Audit-Logs sind derzeit nicht sicher vor Netzwerkausfällen. Wenn die Logeinträge nicht in Google Cloud exportiert werden können, werden sie gelöscht.
Anthos GKE API und Anthos Audit API aktivieren
So verwenden Sie Cloud-Audit-Logs mit GKE On-Prem:
Wenn Sie Anthos 1.4.x oder eine ältere Version verwenden, aktivieren Sie die Anthos GKE API.
Wenn Sie Anthos 1.5 oder höher verwenden, aktivieren Sie die Anthos Audit API.
Wenn Sie sich nicht sicher sind oder ein Upgrade auf Anthos 1.5 durchführen möchten, aktivieren Sie beide.
Dienstkonto für Cloud-Audit-Logs erstellen
Sie haben bereits mehrere Dienstkonten, die Sie für die Verwendung mit GKE On-Prem erstellt haben. Für dieses Alphafeature müssen Sie ein zusätzliches Dienstkonto erstellen und auf die Zulassungsliste setzen lassen.
Erstellen Sie ein Cloud-Audit-Log-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.
Ihr Dienstkonto zulassen
Wenn Sie beantragen möchten, dass Ihr Cloud-Audit-Log-Dienstkonto auf die weiße Liste gesetzt wird, füllen Sie das Cloud-Audit-Logs für Anthos-Cluster im VMware-Alphaformular aus. Du erhältst eine E-Mail-Benachrichtigung, wenn die Genehmigung auf den zulässigen Eintrag abgeschlossen ist. Ihr Dienstkonto muss auf die weiße Liste gesetzt werden, bevor Sie einen Administratorcluster oder einen Nutzercluster erstellen können, der Cloud-Audit-Logs aktiviert.
Administratorcluster mit aktivierten Cloud-Audit-Logs erstellen
Sie können Cloud-Audit-Logs nur 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 in der Anleitung Administratorcluster erstellen.
Nachdem Sie
gkectl create-config
ausgeführt haben, füllen Sie Ihre Konfigurationsdateiadmin-cluster.yaml
wie gewohnt, aber füllen Sie auch den neuen AbschnittcloudAuditLogging
.Legen Sie für
cloudAuditLogging.projectId
die Projekt-ID des Google Cloud-Projekts fest, in dem Sie Audit-Logs zu Ihrem Administratorcluster aufrufen möchten.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.serviceAccountKeyPath
den Pfad der JSON-Schlüsseldatei für Ihr Cloud-Audit-Log-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
Falls Sie noch keinen Administratorcluster erstellt haben, lesen Sie die Anleitung unter Administratorcluster erstellen.
Wenn Sie bereits einen Administratorcluster haben, erstellen Sie einen neuen Nutzercluster. Folgen Sie dazu der Anleitung unter Zusätzliche Nutzercluster erstellen.
Nachdem Sie
gkectl create-config
ausgeführt haben, füllen Sie Ihre Konfigurationsdateiuser-cluster.yaml
wie gewohnt, aber füllen Sie auch den neuen AbschnittcloudAuditLogging
.Legen Sie für
cloudAuditLogging.projectId
die Projekt-ID des Google Cloud-Projekts fest, in dem Sie Audit-Logs zu Ihrem Nutzercluster aufrufen möchten.Legen Sie für
cloudAuditLogging.clusterLocation
eine Google Cloud-Region fest, in der Audit-Logs gespeichert werden sollen. Es empfiehlt sich, eine Region auszuwählen, die sich in der Nähe Ihres lokalen Rechenzentrums befindet.Legen Sie für
cloudAuditLogging.serviceAccounKeyPath
den Pfad der JSON-Schlüsseldatei für Ihr Cloud-Audit-Log-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.
Cloud-Audit-Logging in einem vorhandenen Nutzercluster aktivieren
Cloud-Audit-Logs können mit dem Befehl gkectl update cluster
auf einem vorhandenen Nutzercluster aktiviert werden.
Füllen Sie den Abschnitt cloudAuditLogging
der Datei user-cluster.yaml
aus. Weitere Informationen zu den einzelnen Feldern finden Sie unter Nutzercluster mit aktivierten Cloud-Audit-Logs erstellen.
Führen Sie dann diesen Befehl aus:
gkectl update cluster --config [USER_CLUSTER_YAML] --kubeconfig [ADMIN_CLUSTER_KUBECONFIG]
Cloud-Audit-Logging in einem vorhandenen Nutzercluster deaktivieren
Öffnen Sie die Datei
user-cluster.yaml
, die Ihren Nutzercluster beschreibt.Löschen Sie den Abschnitt
cloudAuditLogging
oder kommentieren Sie ihn aus und speichern Sie die Datei.Führen Sie den folgenden Befehl aus, um den Nutzercluster zu aktualisieren:
gkectl update cluster --config [USER_CLUSTER_YAML] --kubeconfig [ADMIN_CLUSTER_KUBECONFIG]
Auf Anthos-Cluster in Audit-Logs von VMware 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
undtolerations
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 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.