Organiza tus páginas con colecciones
Guarda y categoriza el contenido según tus preferencias.
En este documento, se describe cómo usar los registros de auditoría de Cloud para Google Distributed Cloud.
Google Distributed Cloud usa el registro de auditoría de Kubernetes, que mantiene un registro cronológico de las llamadas realizadas al servidor de la API de Kubernetes de un clúster. Los registros de auditoría son útiles para investigar solicitudes a la API sospechosas y recopilar estadísticas. Para obtener información sobre el registro de auditoría de la API de GKE On-Prem, consulta Registro de auditoría de la API de Cloud.
Acerca de los Registros de auditoría de Cloud
Los registros de auditoría se escriben en Registros de auditoría de Cloud en tu proyecto de Google Cloud. Escribir en los registros de auditoría de Cloud tiene varios beneficios en comparación con escribir en el disco o incluso capturar registros en un sistema de registro local:
Los registros de auditoría para todos los clústeres de GKE se pueden centralizar.
Las entradas de registro escritas en los Registros de auditoría de Cloud son inmutables.
Las entradas de los registros de auditoría de Cloud se retienen durante 400 días.
La función de Registros de auditoría de Cloud se incluye en el precio de Google Distributed Cloud.
Puedes configurar Google Distributed Cloud para escribir registros en el disco o en los registros de auditoría de Cloud.
Registro de auditoría basado en discos
Si los Registros de auditoría de Cloud se inhabilitan de forma explícita, los registros de auditoría en Google Distributed Cloud se escriben en un disco persistente para que los reinicios y las actualizaciones del clúster no causen la desaparición de los registros. Google Distributed Cloud retiene hasta 1 GiB de entradas de registro de auditoría.
Accede a los registros de auditoría basados en discos mediante el acceso a los nodos del plano de control. Los registros se encuentran en el directorio /var/log/apiserver/.
Registros de auditoría de Cloud
Las entradas de registro de auditoría de la actividad del administrador de todos los servidores de la API de Kubernetes se envían a Google Cloud con el proyecto y la ubicación que especifiques cuando crees un clúster de usuario. Para almacenar en búfer y escribir entradas de registro en los registros de auditoría de Cloud, Google Distributed Cloud implementa un conjunto de daemons audit-proxy que se ejecuta en los nodos del plano de control.
Limitaciones
Los registros de auditoría de Cloud para Google Distributed Cloud tienen las siguientes limitaciones:
No se admite el registro de acceso a los datos.
No se admite la modificación de la política de auditoría de Kubernetes.
Los registros de auditoría de Cloud no es resiliente a las interrupciones de red ampliada. Si las entradas de registro no se pueden exportar a Google Cloud, se almacenarán en caché en un búfer de disco de 10 GiB. Si ese búfer se llena, se descartan las entradas más antiguas.
Crea una cuenta de servicio para los registros de auditoría de Cloud
Antes de poder usar Cloud Logging y Cloud Monitoring con Google Distributed Cloud, primero debes configurar lo siguiente:
Crea un lugar de trabajo de Cloud Monitoring dentro del proyecto de Google Cloud, si todavía no tienes uno.
En la consola de Google Cloud, haz clic en el siguiente botón y sigue el flujo de trabajo.
Haz clic en Ejecutar consulta para mostrar todos los registros de auditoría de los clústeres de Google Distributed Cloud que se configuraron para acceder a este proyecto.
gcloud
Enumera las dos primeras entradas en el registro de actividad de administrador de tu proyecto que se aplican al tipo de recurso k8s_cluster:
Los resultados muestran dos entradas de registro. Ten en cuenta que para cada entrada de registro, el campo logName tiene el valor projects/PROJECT_ID/logs/externalaudit.googleapis.com%2Factivity, y protoPayload.serviceName es igual a anthosgke.googleapis.com.
Política de auditoría
La política de auditoría de Kubernetes define reglas para los eventos que se registren como entradas de registro y especifica qué datos deben incluir las entradas del registro. No se admite el cambio de esta política para modificar el comportamiento de los registros de auditoría de Cloud.
[[["Fácil de comprender","easyToUnderstand","thumb-up"],["Resolvió mi problema","solvedMyProblem","thumb-up"],["Otro","otherUp","thumb-up"]],[["Difícil de entender","hardToUnderstand","thumb-down"],["Información o código de muestra incorrectos","incorrectInformationOrSampleCode","thumb-down"],["Faltan la información o los ejemplos que necesito","missingTheInformationSamplesINeed","thumb-down"],["Problema de traducción","translationIssue","thumb-down"],["Otro","otherDown","thumb-down"]],["Última actualización: 2025-01-02 (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."]]
