Mantieni tutto organizzato con le raccolte
Salva e classifica i contenuti in base alle tue preferenze.
Questo documento descrive come utilizzare Cloud Audit Logs per Google Distributed Cloud (solo software) su bare metal. Google Distributed Cloud utilizza Kubernetes Audit
Logging,
che mantiene un record cronologico delle chiamate effettuate a un server dell'API Kubernetes del cluster. I log di controllo sono utili per analizzare le richieste API sospette e per
raccogliere statistiche. Per informazioni sull'audit logging per l'API GKE On-Prem, consulta Audit logging dell'API Cloud.
Informazioni su Cloud Audit Logs
I log di controllo vengono scritti in Cloud Audit Logs nel tuo progettoGoogle Cloud . La scrittura in Cloud Audit Logs offre diversi vantaggi rispetto alla scrittura su disco o all'acquisizione di log in un sistema di logging on-premise:
Gli audit log per tutti i cluster GKE possono essere centralizzati.
Le voci di log scritte in Cloud Audit Logs sono immutabili.
Le voci di Cloud Audit Logs vengono conservate per 400 giorni.
La funzionalità Cloud Audit Logs è inclusa nel prezzo di
Google Distributed Cloud solo software.
Puoi configurare Google Distributed Cloud per scrivere i log su disco o in Cloud Audit Logs.
Audit logging basato su disco
Se Cloud Audit Logs è disattivato in modo esplicito, gli audit log vengono scritti su un disco permanente in modo che i riavvii e gli upgrade del cluster non causino la scomparsa dei log.
Il software Google Distributed Cloud conserva solo fino a 1 GiB di voci di audit log.
Accedi agli audit log basati su disco eseguendo l'accesso ai nodi del control plane. I log
si trovano nella directory /var/log/apiserver/.
Cloud Audit Logs
Le voci di audit log per le attività di amministrazione di tutti i server API Kubernetes vengono inviate a
Google Cloud, utilizzando il progetto e la località specificati durante la
creazione di un cluster utente. Per memorizzare nel buffer e scrivere le voci di log in Cloud Audit Logs,
Google Distributed Cloud esegue il deployment di un set di daemon audit-proxy che viene eseguito sui nodi del piano di controllo.
Limitazioni
Su bare metal, Cloud Audit Logs presenta le seguenti limitazioni:
La registrazione dell'accesso ai dati non è supportata.
La modifica della policy di controllo di Kubernetes non è supportata.
Cloud Audit Logs non è resiliente a interruzioni di rete prolungate. Se le voci di log non possono essere esportate in Google Cloud, vengono memorizzate nella cache in un buffer del disco da 10 GB. Se il buffer si riempie, le voci meno recenti vengono
eliminate.
Un progetto può supportare fino a circa 1000 service account da utilizzare con
Cloud Audit Logs. Più cluster possono utilizzare lo stesso account di servizio.
Creazione di un account di servizio per Cloud Audit Logs
Prima di poter utilizzare Cloud Logging e Cloud Monitoring con
Google Distributed Cloud solo software, devi prima configurare quanto segue:
Crea un workspace Cloud Monitoring all'interno del progetto Google Cloud , se non ne hai già uno.
Nella console Google Cloud , fai clic sul seguente pulsante e segui il flusso di lavoro.
Fai clic su Esegui query per visualizzare tutti i log di controllo dei cluster configurati per accedere a questo progetto.
gcloud
Elenca le prime due voci di log nel log dell'Log delle attività di amministrazione del tuo progetto che
si applicano al tipo di risorsa k8s_cluster:
gcloudloggingread\'logName="projects/PROJECT_ID/logs/externalaudit.googleapis.com%2Factivity" \ AND resource.type="k8s_cluster" \ AND protoPayload.serviceName="anthosgke.googleapis.com" '\--limit2\--freshness300d
Sostituisci PROJECT_ID con l'ID progetto.
L'output mostra due voci di log. Tieni presente che per ogni voce di log, il
campo logName ha il valore
projects/PROJECT_ID/logs/externalaudit.googleapis.com%2Factivity
e protoPayload.serviceName è uguale a anthosgke.googleapis.com.
Criteri di audit
I criteri di controllo di Kubernetes definiscono le regole per gli eventi registrati come voci di log e specificano i dati che devono includere. La modifica di questo
criterio per modificare il comportamento di Cloud Audit Logs non è supportata.
[[["Facile da capire","easyToUnderstand","thumb-up"],["Il problema è stato risolto","solvedMyProblem","thumb-up"],["Altra","otherUp","thumb-up"]],[["Difficile da capire","hardToUnderstand","thumb-down"],["Informazioni o codice di esempio errati","incorrectInformationOrSampleCode","thumb-down"],["Mancano le informazioni o gli esempi di cui ho bisogno","missingTheInformationSamplesINeed","thumb-down"],["Problema di traduzione","translationIssue","thumb-down"],["Altra","otherDown","thumb-down"]],["Ultimo aggiornamento 2025-08-14 UTC."],[],[],null,["This document describes how to use Cloud Audit Logs for Google Distributed Cloud\n(software only) on bare metal. Google Distributed Cloud uses [Kubernetes Audit\nLogging](https://kubernetes.io/docs/tasks/debug-application-cluster/audit/),\nwhich keeps a chronological record of calls made to a cluster Kubernetes API\nserver. Audit logs are useful for investigating suspicious API requests and for\ncollecting statistics. For information about audit logging for the\nGKE On-Prem API, see [Cloud API audit\nlogging](/kubernetes-engine/distributed-cloud/bare-metal/docs/how-to/audit-logging-api).\n| **Note:** Starting with Google Distributed Cloud release 1.9.0, Cloud Audit Logs is enabled by default. Cloud Audit Logs is automatically enabled for 1.8.x clusters that are upgraded to 1.32.400-gke.68 unless it was explicitly disabled for the 1.8.x cluster by setting `disableCloudAuditLogging` to `true`.\n\nAbout Cloud Audit Logs\n\nAudit logs are written to [Cloud Audit Logs](/logging/docs/audit) in your\nGoogle Cloud project. Writing to Cloud Audit Logs has several benefits over writing to\ndisk or capturing logs in an on-premises logging system:\n\n- Audit logs for all GKE clusters can be centralized.\n- Log entries written to Cloud Audit Logs are immutable.\n- Cloud Audit Logs entries are retained for 400 days.\n- Cloud Audit Logs feature is included in the price of Google Distributed Cloud software-only.\n- You can configure Google Distributed Cloud to write logs to disk or to Cloud Audit Logs.\n\nDisk-based audit logging\n\nIf Cloud Audit Logs is disabled explicitly, audit logs are written to a persistent\ndisk so that cluster restarts and upgrades don't cause the logs to disappear.\nGoogle Distributed Cloud software-only retains up to 1 GiB of audit log\nentries.\n\nAccess the disk-based audit logs by logging into control plane Nodes. The logs\nare located in the `/var/log/apiserver/` directory.\n\nCloud Audit Logs\n\nAdmin Activity audit log entries from all Kubernetes API servers are sent to\nGoogle Cloud, using the project and location that you specify when you\ncreate a user cluster. To buffer and write log entries to Cloud Audit Logs,\nGoogle Distributed Cloud deploys an `audit-proxy` daemon set that runs on the control\nplane nodes.\n\nLimitations\n\nOn bare metal, Cloud Audit Logs has the following limitations:\n\n- Data access logging isn't supported.\n- Modifying the Kubernetes audit policy is not supported.\n- Cloud Audit Logs isn't resilient to extended network outages. If the log entries can't be exported to Google Cloud, they are cached in a 10 GiB disk buffer. If that buffer fills, then the oldest entries are dropped.\n - One project can support up to approximately 1000 service accounts for use with Cloud Audit Logs. Multiple clusters can use the same service account.\n\nCreating a service account for Cloud Audit Logs\n\nBefore you can use Cloud Logging and Cloud Monitoring with\nGoogle Distributed Cloud software-only, you must first configure the following:\n\n1. Create a Cloud Monitoring Workspace within the Google Cloud project, if you\n don't have one already.\n\n In the Google Cloud console, click the following button and follow the\n workflow.\n\n [Go to Monitoring](https://console.cloud.google.com/monitoring)\n2. Click the following buttons to enable the required APIs:\n\n [Enable the Anthos Audit API](https://console.cloud.google.com/apis/library/anthosaudit.googleapis.com)\n\n [Enable the Stackdriver API](https://console.cloud.google.com/apis/library/stackdriver.googleapis.com)\n\n [Enable the Monitoring API](https://console.cloud.google.com/apis/library/monitoring.googleapis.com)\n\n [Enable the Logging API](https://console.cloud.google.com/apis/library/logging.googleapis.com)\n3. Assign the following IAM roles to the service account used by\n the Stackdriver agents:\n\n - `logging.logWriter`\n - `monitoring.metricWriter`\n - `stackdriver.resourceMetadata.writer`\n - `monitoring.dashboardEditor`\n\n| **Warning:** before deleting this service account, be sure to replace it with the new service account in the cluster configuration first! See [Rotate service\n| account keys](/kubernetes-engine/distributed-cloud/bare-metal/docs/how-to/update-secrets). If you forget to do this, follow [the guide to clean\n| up](/kubernetes-engine/distributed-cloud/bare-metal/docs/troubleshooting/observability#sa-leakage).\n\nAccessing Cloud Audit Logs \n\nConsole\n\n1. In the Google Cloud console, go to the **Logs Explorer** page in the\n **Logging** menu.\n\n [Go to the Logs Explorer](https://console.cloud.google.com/logs/query)\n\n If the **Legacy Logs Viewer** page opens, choose **Upgrade to the new\n Logs Explorer** from the **Upgrade** drop-down menu.\n2. Click **Query** to access the field for submitting queries.\n\n3. Fill the field with the following query:\n\n resource.type=\"k8s_cluster\"\n logName=\"projects/\u003cvar translate=\"no\"\u003ePROJECT_ID\u003c/var\u003e/logs/externalaudit.googleapis.com%2Factivity\"\n protoPayload.serviceName=\"anthosgke.googleapis.com\"\n\n Replace \u003cvar translate=\"no\"\u003ePROJECT_ID\u003c/var\u003e with your project ID.\n4. Click **Run query** to display all audit logs from clusters that were\n configured to sign in to this project.\n\ngcloud\n\nList the first two log entries in your project's Admin Activity log that\napply to the `k8s_cluster` resource type: \n\n gcloud logging read \\\n 'logName=\"projects/\u003cvar translate=\"no\"\u003ePROJECT_ID\u003c/var\u003e/logs/externalaudit.googleapis.com%2Factivity\" \\\n AND resource.type=\"k8s_cluster\" \\\n AND protoPayload.serviceName=\"anthosgke.googleapis.com\" ' \\\n --limit 2 \\\n --freshness 300d\n\nReplace \u003cvar translate=\"no\"\u003ePROJECT_ID\u003c/var\u003e with your project ID.\n\nThe output shows two log entries. Notice that for each log entry, the\n`logName` field has the value\n`projects/`\u003cvar translate=\"no\"\u003ePROJECT_ID\u003c/var\u003e`/logs/externalaudit.googleapis.com%2Factivity`\nand `protoPayload.serviceName` is equal to `anthosgke.googleapis.com`.\n\nAudit policy\n\nThe Kubernetes audit policy defines rules for which events are recorded as log\nentries and specifies what data the log entries should include. Changing this\npolicy to modify Cloud Audit Logs behavior isn't supported."]]
