Learn how VMware Tanzu Mission Control logs events that occur in your organization.
To help you monitor the activities that occur in your organization, Tanzu Mission Control provides logging of audit events. This includes audit logging of service-level actions that are performed through Tanzu Mission Control, as well as cluster-level actions that take place on Tanzu Kubernetes clusters that you provisioned through Tanzu Mission Control.
Tanzu Mission Control Service Audit Logging
As an organization administrator, you can monitor the activities that are initiated through Tanzu Mission Control, using the service audit logging capability.
- what was done
- who performed the action
- when and where the action occurred
Because some actions result in subsequent actions, Tanzu Mission Control logs all pertinent events from the original action performed through Tanzu Mission Control to the resulting actions that are initiated on your clusters.
- Tanzu Mission Control event log entries are retained in the service for 60 days, so you can generate an audit report going back up to 60 days.
- The maximum date range for an audit report is seven days.
- Generated audit reports are retained for 60 days after generation, after which they are deleted.
Audit Logging in Your Provisioned Cluster
When you provision a new Tanzu Kubernetes cluster through Tanzu Mission Control, preconfigured audit logging is enabled for the cluster. Although the audit logging policy is not configurable, logging is set to commonly useful levels for certain operations to capture important information without inflating the size of the logs. The logging levels are listed below with the types of operations that use each one.
- kube-proxy watching endpoint resource
- kubelet getting nodes and node status
- Controller manager, scheduler and endpoint controller reading the endpoints
- API server getting namespaces and namespace finalizers
- Controller manager getting metrics
- Read-only APIs like /swagger, /version, and /healthz
- All getting events
- Garbage collector getting resources
- Tanzu Mission Control getting resources
- Config maps, secrets, and token reviews - because they can contain sensitive data
- kubelet updating nodes and node status
- All read-only operations - log the request, but not the data returned back
- All other operations, including write operations like create, update, and delete
- Audit log entries are written to audit.log files in the /var/log/kubernetes/ directory on the control plane nodes for your cluster. You can aggregate the logs, if desired, using a log collector and a log aggregation service.
- The maximum size for a log file is 100 MB. When this limit is reached, a new log file is started. The rotated files are also stored in the /var/log/kubernetes/ directory.
- The maximum number of log files stored on a node is 20 (for a total max size of 2 GB for all stored logs). When this limit is reached, a new log file replaces the oldest log file.
- A log file is stored for a maximum of 7 days, after which it is deleted. This limit is not often hit on a typical cluster, as clusters running workloads tend to churn through the maximum number of log files more quickly.