
Monitor Audit Logs to Safeguard Your Kubernetes Infrastructure
The Kubernetes audit log datasource — introduced in CrowdSec Security Engine 1.5 — provides you with a webhook to receive events from the Kubernetes API server, helping you to analyze audit logs in real-time and take action against potential threats.
The CrowdSec collection k8s-audit is capable of detecting various security issues within your Kubernetes environment.
- Identify anonymous access attempts to the Kubernetes API
- Detect brute force attacks against the API server
- Monitor for pod creations with host networking enabled
- Identify unauthorized executions within pods (using kubectl)
- Track pods that mount sensitive host folders
- Flag the creation of privileged pods
- Detect unauthorized requests originating from service accounts
By harnessing the power of Crowdsec and its new Kubernetes audit log datasource, you can proactively safeguard your Kubernetes infrastructure against these potential threats. Let's dive in and explore the steps to leverage this powerful combination of technologies.
What are Kubernetes audit logs?
Kubernetes audit logs are a record of events that occur within a Kubernetes cluster. These events include actions performed by users and applications, such as creating or deleting resources and changes to the configuration of the cluster itself. You can use audit logs to track activity within the cluster and identify potential security threats, as well as for compliance purposes. By enabling audit logs in Kubernetes, administrators can gain visibility into what's happening in their cluster and take action to prevent or mitigate security incidents.
Architecture
The diagram below shows the architecture we will be setting up in this tutorial.

Prerequisites
To follow along with this tutorial, you will need the following tools installed:
Note: As the audit log feature is different from one Kubernetes distribution to another (for example, GKE, EKS, and AKS are using bridge/CloudWatch to access the audit logs), we decided that for the purposes of this tutorial, we will install CrowdSec externally to the Kubernetes cluster. However, it's also possible to configure the Kubernetes cluster to export logs to a file, then install the CrowdSec Security Engine inside the cluster using the Helm chart, and use the file datasource to ingest the logs.
Setting up the environment
Install and configure the Kubernetes cluster
Before creating the cluster using kind, we need to create the configuration files that will enable the audit log.
We can start by creating the first file audit-policy.yaml that will define the audit policies:
Next, we need to create the second file audit-webhook.yaml that will define the webhook configuration:
Now let’s create the kind config file kind.yaml that defines the cluster configuration:
Finally, we can create the cluster using kind:
Configuring the Crowdsec Security Engine
Once the cluster is created, we need to configure the CrowdSec Security Engine to receive logs from the Kubernetes cluster.
We start with the acquisition configuration file /etc/crowdsec/acquis.yaml:
Here, we configure the new datasource.
Warning: In our example, we exposed the webhook on HTTP, but in a production environment, we suggest installing a reverse proxy in front of the webhook to use HTTPS and to add authentication.
Now we can install the k8s-audit collection:
This collection contains the audit log parser and the scenarios to alert suspicious events and take decisions on some other events (like brute-forcing the API server).
For this example, we want to be alerted to suspicious events, so we will configure Slack notifications. To do so, we need to update the /etc/crowdsec/profiles.yaml file and add the following lines at the beginning:
And set up the Slack notification in the /etc/crowdsec/notifications/slack.yaml file:
Note: You need to get the Slack webhook URL from your Slack workspace.
Now that we are all set with the CrowdSec Security Engine installation, we can restart the CrowdSec service:
To check that the Security Engine is running correctly, check the logs:
Here’s what you should see:
You can also check the metrics using cscli:

Detection
Now that we have configured the cluster and the CrowdSec Security Engine, we can test the detection mechanism.
For that, we will create a new pod in the default namespace using this manifest debug-pod.yaml:
This pod will be created with the privileged flag, which is a security risk that will be triggered by audit logs and detected by the CrowdSec Security Engine.
We can apply this manifest using kubectl:
We will now get a shell in the pod:
The CrowdSec logs, should now detect the suspicious events:
As you can see, the Security Engine detected three of the scenarios included in the k8s-audit collection:
- Pod creation mounting a sensitive host folder in the cluster
- Privileged pod creation in the cluster
- Executing a command in a pod
And here are our Slack notifications:

Wrapping up
In this tutorial, we explored the new Kubernetes audit log datasource in CrowdSec Security Engine 1.5 and how to use it to enhance the security of your Kubernetes workloads. By setting up a local Kubernetes cluster with audit logs enabled, configuring a webhook in CrowdSec, and installing the new datasource, you can monitor audit logs in real-time and take action against a number of potential threats.
In one of our upcoming tutorials, we will go deeper into this feature and explore how to configure the audit log for specific hosted K8s providers (GKE, EKS, AKS). In the meantime, check out the CrowdSec documentation and community resources for more information on Kubernetes audit log datasource in CrowdSec Security Engine 1.5.