Os clusters do Anthos em bare metal agora são o Google Distributed Cloud (somente software) em bare metal. Para mais informações, consulte a visão geral do produto.
Usar a geração de registros de auditoria do Kubernetes
Mantenha tudo organizado com as coleções
Salve e categorize o conteúdo com base nas suas preferências.
Neste documento, descrevemos como usar os registros de auditoria do Cloud para o Google Distributed Cloud (somente software) em bare metal. O Google Distributed Cloud usa o Registro de auditoria do
Kubernetes,
que mantém um registro cronológico das chamadas feitas para o servidor da API Kubernetes de um cluster. Os registros de auditoria são úteis para investigar solicitações de API suspeitas e
coletar estatísticas. Para informações sobre a geração de registros de auditoria da
API GKE On-Prem, consulte
Geração de registros de auditoria da API Cloud.
Sobre os registros de auditoria do Cloud
Os registros de auditoria são gravados nos registros de auditoria do Cloud no seu projetoGoogle Cloud . A gravação em registros de auditoria do Cloud tem vários benefícios
em relação à gravação em disco ou à captura de registros em um sistema de geração de registros no local:
Os registros de auditoria de todos os clusters do GKE podem ser centralizados.
As entradas de registro gravadas nos registros de auditoria do Cloud são imutáveis.
As entradas de registros de auditoria do Cloud são mantidas por 400 dias.
O recurso Registros de auditoria do Cloud está incluído no preço do Google Distributed Cloud somente software.
É possível configurar o Google Distributed Cloud para gravar registros no disco ou nos
registros de auditoria do Cloud.
Geração de registros de auditoria baseada em disco
Se os registros de auditoria do Cloud forem desativados explicitamente, os registros de auditoria serão gravados em um disco
permanente para que as reinicializações e upgrades de clusters não façam com que os registros desapareçam.
O Google Distributed Cloud somente software retém até 1 GiB de entradas de registro de auditoria.
Acesse os registros de auditoria baseados em disco fazendo login nos nós do plano de controle. Os registros
estão localizados no diretório /var/log/apiserver/.
Registros de auditoria do Cloud
As entradas de registro de auditoria de atividade do administrador de todos os servidores da API Kubernetes são enviadas ao
Google Cloud, usando o projeto e o local que você especifica ao
criar um cluster de usuário. Para armazenar em buffer e gravar entradas de registro nos registros de auditoria do Cloud,
o Google Distributed Cloud implanta um conjunto de daemon audit-proxy que é executado nos nós do plano
de controle.
Limitações
Em bare metal, os registros de auditoria do Cloud têm as seguintes limitações:
A geração de registros de acesso a dados não é compatível.
Não é possível modificar a política de auditoria do Kubernetes.
O registro de auditoria do Cloud não é resiliente a interrupções estendidas de rede. Se as entradas de registro não puderem ser exportadas para Google Cloud, elas serão armazenadas em cache em um buffer de disco de 10 GiB. Se esse buffer for preenchido, as entradas mais antigas serão
descartadas.
Um projeto pode oferecer suporte a aproximadamente 1.000 contas de serviço para uso com os Registros de auditoria do Cloud. Vários clusters podem usar a mesma conta de serviço.
Como criar uma conta de serviço para Registros de auditoria do Cloud
Antes de usar o Cloud Logging e o Cloud Monitoring com
o software da Google Distributed Cloud, configure o seguinte:
Crie um espaço de trabalho do Cloud Monitoring no projeto Google Cloud , se você ainda não tiver um.
No console do Google Cloud , clique no botão a seguir e siga o
fluxo de trabalho.
Clique em Executar consulta para mostrar todos os registros de auditoria dos clusters
configurados para fazer login nesse projeto.
gcloud
Liste as duas primeiras entradas no registro de atividade do administrador do projeto que se aplicam ao tipo de recurso 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
Substitua PROJECT_ID pela ID do seu projeto.
A saída mostra duas entradas de registro. Observe que, para cada entrada de registro, o
campo logName tem o valor
projects/PROJECT_ID/logs/externalaudit.googleapis.com%2Factivity,
e protoPayload.serviceName é igual a anthosgke.googleapis.com.
Política de auditoria
A política de auditoria do Kubernetes define regras para quais eventos são gravados como entradas
de registro e especifica quais dados as entradas de registro precisam incluir. No momento,
não é possível alterar essa política para modificar o comportamento dos registros de auditoria do Cloud.
[[["Fácil de entender","easyToUnderstand","thumb-up"],["Meu problema foi resolvido","solvedMyProblem","thumb-up"],["Outro","otherUp","thumb-up"]],[["Difícil de entender","hardToUnderstand","thumb-down"],["Informações incorretas ou exemplo de código","incorrectInformationOrSampleCode","thumb-down"],["Não contém as informações/amostras de que eu preciso","missingTheInformationSamplesINeed","thumb-down"],["Problema na tradução","translationIssue","thumb-down"],["Outro","otherDown","thumb-down"]],["Última atualização 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."]]
