Restez organisé à l'aide des collections
Enregistrez et classez les contenus selon vos préférences.
Ce document explique comment utiliser Cloud Audit Logs pour Google Distributed Cloud (logiciel uniquement) sur Bare Metal. Google Distributed Cloud utilise la journalisation d'audit Kubernetes, qui conserve un enregistrement chronologique des appels passés au serveur de l'API Kubernetes d'un cluster. Les journaux d'audit sont utiles pour analyser les requêtes API suspectes et collecter des statistiques. Pour en savoir plus sur les journaux d'audit de l'API GKE On-Prem, consultez Journaux d'audit des API Cloud.
À propos de Cloud Audit Logs
Les journaux d'audit sont écrits dans Cloud Audit Logs de votre projetGoogle Cloud . Écrire dans Cloud Audit Logs présente plusieurs avantages par rapport à l'écriture sur disque, voire à la capture de journaux dans un système de journalisation sur site :
Les journaux d'audit de tous les clusters GKE peuvent être centralisés.
Les entrées de journal écrites dans Cloud Audit Logging sont immuables.
Les entrées Cloud Audit Logging sont conservées pendant 400 jours.
Cloud Audit Logs est inclus dans le prix de Google Distributed Cloud (logiciel uniquement).
Vous pouvez configurer Google Distributed Cloud pour écrire des journaux sur disque ou dans Cloud Audit Logs.
Journaux d'audit sur disque
Si Cloud Audit Logs est désactivé explicitement, les journaux d'audit sont écrits sur un disque persistant, de sorte que les redémarrages et les mises à niveau du cluster n'entraînent pas leur disparition.
Google Distributed Cloud (logiciel uniquement) conserve jusqu'à 1 Gio d'entrées de journal d'audit.
Accédez aux journaux d'audit sur disque en vous connectant aux nœuds du plan de contrôle. Les journaux se trouvent dans le répertoire /var/log/apiserver/.
Cloud Audit Logs
Les entrées de journal d'audit pour les activités d'administration de tous les serveurs d'API Kubernetes sont envoyées àGoogle Cloud, en utilisant le projet et l'emplacement que vous spécifiez lorsque vous créez un cluster d'utilisateur. Pour mettre en mémoire tampon et écrire des entrées de journal dans Cloud Audit Logs, Google Distributed Cloud déploie un ensemble de daemons audit-proxy qui s'exécute sur les nœuds du plan de contrôle.
Limites
Sur Bare Metal, Cloud Audit Logs présente les limites suivantes :
Il n'est pas possible de journaliser les accès aux données.
La modification de la stratégie d'audit Kubernetes n'est pas acceptée.
Cloud Audit Logging n'est pas résilient aux pannes réseau étendues. Si les entrées de journal ne peuvent pas être exportées vers Google Cloud, elles sont mises en cache dans un tampon de disque de 10 Gio. Si ce tampon remplit, les entrées les plus anciennes sont supprimées.
Un projet peut accepter jusqu'à environ 1 000 comptes de service à utiliser avec Cloud Audit Logs. Plusieurs clusters peuvent utiliser le même compte de service.
Créer un compte de service pour Cloud Audit Logging
Pour pouvoir utiliser Cloud Logging et Cloud Monitoring avec Google Distributed Cloud (logiciel uniquement), vous devez d'abord configurer les éléments suivants :
Créez un espace de travail Cloud Monitoring dans le projet Google Cloud , si vous n'en possédez pas déjà un.
Dans la console Google Cloud , cliquez sur le bouton suivant et suivez le workflow.
Si la page Ancienne visionneuse de journaux s'ouvre, sélectionnez Mettre à niveau vers le nouvel explorateur de journaux dans le menu déroulant Mettre à jour.
Cliquez sur Requête pour accéder au champ permettant d'envoyer des requêtes.
Cliquez sur Exécuter la requête pour afficher tous les journaux d'audit des clusters configurés pour se connecter à ce projet.
gcloud
Répertoriez les deux premières entrées du journal d'activité d'administration de votre projet qui s'appliquent au type de ressource 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
Remplacez PROJECT_ID par l'ID du projet.
La sortie affiche deux entrées de journal. Notez que pour chaque entrée de journal, le champ logName a la valeur projects/PROJECT_ID/logs/externalaudit.googleapis.com%2Factivity et que protoPayload.serviceName est égal à anthosgke.googleapis.com.
Règle d'audit
La stratégie d'audit Kubernetes définit les règles pour lesquelles des événements sont enregistrés en tant qu'entrées de journal et spécifie les données que les entrées de journal doivent inclure. Il n'est pas possible de modifier cette stratégie pour modifier le comportement de Cloud Audit Logs.
Sauf indication contraire, le contenu de cette page est régi par une licence Creative Commons Attribution 4.0, et les échantillons de code sont régis par une licence Apache 2.0. Pour en savoir plus, consultez les Règles du site Google Developers. Java est une marque déposée d'Oracle et/ou de ses sociétés affiliées.
Dernière mise à jour le 2025/08/14 (UTC).
[[["Facile à comprendre","easyToUnderstand","thumb-up"],["J'ai pu résoudre mon problème","solvedMyProblem","thumb-up"],["Autre","otherUp","thumb-up"]],[["Difficile à comprendre","hardToUnderstand","thumb-down"],["Informations ou exemple de code incorrects","incorrectInformationOrSampleCode","thumb-down"],["Il n'y a pas l'information/les exemples dont j'ai besoin","missingTheInformationSamplesINeed","thumb-down"],["Problème de traduction","translationIssue","thumb-down"],["Autre","otherDown","thumb-down"]],["Dernière mise à jour le 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."]]
