tencent cloud

Tencent Kubernetes Engine

Release Notes and Announcements
Release Notes
Announcements
Release Notes
Product Introduction
Overview
Strengths
Architecture
Scenarios
Features
Concepts
Native Kubernetes Terms
Common High-Risk Operations
Regions and Availability Zones
Service Regions and Service Providers
Open Source Components
Purchase Guide
Purchase Instructions
Purchase a TKE General Cluster
Purchasing Native Nodes
Purchasing a Super Node
Getting Started
Beginner’s Guide
Quickly Creating a Standard Cluster
Examples
Container Application Deployment Check List
Cluster Configuration
General Cluster Overview
Cluster Management
Network Management
Storage Management
Node Management
GPU Resource Management
Remote Terminals
Application Configuration
Workload Management
Service and Configuration Management
Component and Application Management
Auto Scaling
Container Login Methods
Observability Configuration
Ops Observability
Cost Insights and Optimization
Scheduler Configuration
Scheduling Component Overview
Resource Utilization Optimization Scheduling
Business Priority Assurance Scheduling
QoS Awareness Scheduling
Security and Stability
TKE Security Group Settings
Identity Authentication and Authorization
Application Security
Multi-cluster Management
Planned Upgrade
Backup Center
Cloud Native Service Guide
Cloud Service for etcd
TMP
TKE Serverless Cluster Guide
TKE Registered Cluster Guide
Use Cases
Cluster
Serverless Cluster
Scheduling
Security
Service Deployment
Network
Release
Logs
Monitoring
OPS
Terraform
DevOps
Auto Scaling
Containerization
Microservice
Cost Management
Hybrid Cloud
AI
Troubleshooting
Disk Full
High Workload
Memory Fragmentation
Cluster DNS Troubleshooting
Cluster kube-proxy Troubleshooting
Cluster API Server Inaccessibility Troubleshooting
Service and Ingress Inaccessibility Troubleshooting
Common Service & Ingress Errors and Solutions
Engel Ingres appears in Connechtin Reverside
CLB Ingress Creation Error
Troubleshooting for Pod Network Inaccessibility
Pod Status Exception and Handling
Authorizing Tencent Cloud OPS Team for Troubleshooting
CLB Loopback
API Documentation
History
Introduction
API Category
Making API Requests
Elastic Cluster APIs
Resource Reserved Coupon APIs
Cluster APIs
Third-party Node APIs
Relevant APIs for Addon
Network APIs
Node APIs
Node Pool APIs
TKE Edge Cluster APIs
Cloud Native Monitoring APIs
Scaling group APIs
Super Node APIs
Other APIs
Data Types
Error Codes
TKE API 2022-05-01
FAQs
TKE General Cluster
TKE Serverless Cluster
About OPS
Hidden Danger Handling
About Services
Image Repositories
About Remote Terminals
Event FAQs
Resource Management
Service Agreement
TKE Service Level Agreement
TKE Serverless Service Level Agreement
Contact Us
Glossary
DokumentasiTencent Kubernetes EngineCloud Native Service Guide TKE Serverless Cluster Guide OPS CenterAudit ManagementCluster Audit

Cluster Audit

PDF
Mode fokus
Ukuran font
Terakhir diperbarui: 2023-05-06 17:36:46
Note:
From now to December 31, 2021, users are exempt from CLS service fees incurred by audit log/event data generated by TKE Serverless for auto-created logsets or auto-created log topics in existing logsets.

Overview

Cluster audit is a feature based on Kubernetes Auditing that can store and search the records of JSON logs with configurable policies generated by kube-apiserver. This feature records the access events of kube-apiserver and records the activities of each user, admin, or system component that has an impact on the cluster in sequence.

Advantages

The cluster audit feature provides another cluster monitoring dimension different from metrics. After cluster audit is enabled, Kubernetes can record every audit log that operates on the cluster. An audit log is a structured record in JSON format, and includes three parts: metadata, requestObject, and responseObject. The metadata (containing the request context information, such as who initiated the request, where it was initiated, and the accessed URI) is a required part. requestObject and responseObject are optional, depending on the audit level. You can learn the following information from logs:
Activities that occur in the cluster.
Activity occurrence time and objects.
Activity triggering time, triggering positions, and observation points.
Activity results and subsequent processing.

An example of how to read the audit log

{
  "kind":"Event",
  "apiVersion":"audit.k8s.io/v1",
  "level":"RequestResponse",
  "auditID":0a4376d5-307a-4e16-a049-24e017******,
  "stage":"ResponseComplete",
  // What happened?
  "requestURI":"/apis/apps/v1/namespaces/default/deployments",
  "verb":"create",
  // Who initiated the request?
  "user":{
    "username":"admin",
      "uid":"admin",
      "groups":[
        "system:masters",
        "system:authenticated"
      ]
  },
  // Where was it initiated?
  "sourceIPs":[
    "10.0.6.68"
  ],
  "userAgent":"kubectl/v1.16.3 (linux/amd64) kubernetes/ald64d8",
  // What happened?
  "objectRef":{
    "resource":"deployments",
    "namespace":"default",
    "name":"nginx-deployment",
    "apiGroup":"apps",
    "apiVersion":"v1"
  },
  // What’s the result?
  "responseStatus":{
    "metadata":{
    },
    "code":201
  },
  // Request and response details
  "requestObject":Object{...},
  "responseObject":Object{...},
  // When did it start/end?
  "requestReceivedTimestamp":"2020-04-10T10:47:34.315746Z",
  "stageTimestamp":"2020-04-10T10:47:34.328942Z",
  // Reason for accepting/rejecting the request
  "annotations":{
    "authorization.k8s.io/decision":"allow",
    "authorization.k8s.io/reason":""
  }
}

TKE Serverless Cluster Audit Policy

Audit level (level)

Unlike common logs, the level of Kubernetes audit logs is more like a kind of verbose configuration, which is used to indicate the degree of detail of the recorded information. There are four audit levels, as listed in the following table:
Parameter
Description
None
Nothing is recorded.
Metadata
The metadata of the request (for example, user, time, resources, and operation) is recorded, excluding the request message body and response message body.
Request
The metadata and request message body are recorded, excluding the response message body.
RequestResponse
All the information is recorded, including the metadata, request message body, and response message body.

Audit stage (stage)

Logs can be recorded at different stages, as listed in the following table:
Parameter
Description
RequestReceived
The log is recorded immediately after a request is received.
ResponseStarted
The log is recorded after the message header of the response is sent. This parameter only applies to persistent connection requests, such as WATCH.
ResponseComplete
The log is recorded after the entire response is sent.
Panic
An error occurs to the internal server and the request fails.

Audit policy

By default, TKE serverless clusters record audit logs when receiving requests. For most operations, audit logs at the RequestResponse level are recorded. The following list shows the exceptions:
For GET, LIST, and WATCH requests, logs at the Request level are recorded.
For requests of Secret, ConfigMap, or TokenReview resources, logs at the Metadata level are recorded.
Logs will not be recorded for the following requests:
Requests sent by system:kube-proxy for monitoring endpoint, service, or service/status resources.
GET requests sent by system:unsecured for ConfigMap resources in the kube-system namespace.
GET requests sent by kubelet for node or node/status resources.
GET and UPDATE requests sent by system:kube-controller-manager, system:kube-scheduler, or system:serviceaccount:endpoint-controller for endpoint resources in the kube-system namespace.
GET requests sent by system:apiserver for namespace, namespace/status, or namespace/finalize resources.
Requests sent to URLs that match /healthz*, /version, or /swagger*.

Directions

Enabling cluster audit

Note
To enable the cluster audit feature, you need to restart kube-apiserver. We recommend that you do not frequently enable and disable the feature.
1. Log in to the TKE console.
2. In the left sidebar, choose Operation Management > Feature Management.
3. On the Feature Management page, select a region and the Serverless cluster type.
4. Locate the cluster for which you want to enable the cluster audit feature in the following cluster list. Click Set in the Operation column on the right.
5. In the Configure features pop-up window, click Edit for the Cluster Auditing feature, as shown below:

6. Check Enable Cluster Auditing. Select the logset and log topic for storing audit logs. We recommend that you select Auto-create Logset, as shown below:

7. Click Confirm to enable the cluster audit feature.
Topik sebelumnya: Configuring Log Collection via YamlTopik selanjutnya: Audit Dashboard

Bantuan dan Dukungan

Apakah halaman ini membantu?

masukan