As Kubernetes’s popularity rises, Kubernetes auditing is a crucial source of data to incorporate into your Kubernetes security strategy. It gives the security and DevOps teams a complete transparency into all operations that take place within the cluster. The audit logging functionality was introduced in Kubernetes 1.11. Auditing logs is an essential part of protecting your Kubernetes cluster since they record the events like initiating a node port service, deleting namespaces, and launching new deployments. This blog explains in detail what Kubernetes auditing is and provides you with information that helps you get started. Before we move on to auditing policy in Kubernetes, let’s first define what auditing is.

What Is Auditing in Kubernetes?

Using Kubernetes auditing, a cluster’s history of events is captured in a series of records that are organized chronologically. The control plane itself, the apps that utilize the Kubernetes API, and the users, all of them provide activities that the cluster audits.

Cluster administrators can utilize auditing to provide answers to some questions like what occurred and when it occurred, who initiated it, what transpired, where it was observed, where it originated, and where it is going which are all revealed.

The lifespan of audit records begins with the kube-apiserver component. Every request provides an audit event at every step of processing, which is then pre-processed in line with a policy and is saved to a backend. The policy determines what is recorded and the backends maintain the records. Two of the current backend implementations are log files and webhooks.

Each request may be placed in a particular stage. The stages and their description are depicted in the following:

What Is the Audit Policy in Kubernetes?

The audit policy specifies the standards for the events that must be reported and the data that must be provided. The audit policy object format is specified by the audit.k8s.io API group. A list of rules is compared to an event when it is processed in an orderly fashion. The event’s audit level is decided by the first matching rule.

None, Metdt, Request, and RequestResponse are the audit levels that are specified.

A file that holds the policy can be passed to the kube-apiserver using the -audit-policy-file switch. If the flag is not set, no events are registered at all. The audit policy file’s rules field has to be filled up. A policy is deemed unlawful if it contains no regulations.

Here is an example of an audit policy file for your help. Here, you may see all the information such as users, groups, resources, and other things.

Remember that audit logs are gathered based on the configured audit policy before you attempt to grasp the audit policy which is given in the following. The events and information that must be recorded are specified by the audit policy. The very first matching rule in the hierarchy of the rules that are specified in the audit policy determines the audit level of the event.

Attached is a complete sample audit policy file that you can refer to understand the details better.

The Kubernetes audit policy file for GKE clusters begins with the rules that describe which events shouldn’t be logged on at all. For instance, this rule specifies that the nodes resources or nodesstatus resources should not report any requests which are made by kubelets. Remember that if the level is None, no matching events should be reported.

The policy file contains a list of rules that are special instances after the list of level None rules. As an example, this special-case rule instructs to log the specific requests at the Metadata level.

An event matches the rule if all of the following are true:

• No preceding rule in the policy file matches the event.
• A resource of the secrets, configmaps, or tokenreviews types is the subject of the request.
• The RequestReceived stage of the call is not covered by the event.

The policy file then contains a collection of general rules following the special-case rule list. You must change the value of $(known_apis) to the value of known apis to view the script’s general rules. After the substitution, a rule appears that reads as follows:

You can log each request at the Metadata level using a simple audit policy file.

What Are Audit Logs and Why You Should Configure Them

Audit logs are highly helpful in a Kubernetes cluster for tracing and tracking the activities and changes to various cluster resources. You can find out who performed what and when by enabling the auditing, which is not enabled by default.

Audit logs serve as a basis for security and compliance and gives insight into the activities that take place in a Kubernetes cluster. You may instantly spot any unusual behavior that occurs in your cluster, such as failed login attempts or attempts to access sensitive Secrets, with correctly configured audit logging. You may collaborate across silos to quickly respond to suspicious activities by employing audits. The implementation of cluster hardening and mitigating any misconfiguration are both aided by routine auditing of the event log data.

Conclusion

We learned what the Kubernetes audit logs exactly are for and what purpose they are used for. We also learned why auditing is crucial to the security of your Kubernetes cluster. The necessity of turning on the audit logs for your Kubernetes cluster is also discussed. For your reference, we provided a sample audit policy file and a detailed explanation of the contents. You can refer to this article if you are new to this concept.