Type to search.

Running Auditbeat on Kubernetes

Serverless

Elastic Cloud Serverless projects are autoscaled environments, fully managed by Elastic and available on Elastic Cloud.

Availability

  • Generally available

    This functionality is generally available and ready for production usage.

Serverless interfaces and procedures might differ from classic Elastic Stack deployments.

Stack

The Elastic Stack includes Elastic's core products such as Elasticsearch, Kibana, Logstash, and Beats.

Availability

  • Generally available

    This functionality is generally available and ready for production usage.

Unless stated otherwise on the page, this functionality is available when your Elastic Stack is deployed on Elastic Cloud Hosted, Elastic Cloud Enterprise, Elastic Cloud on Kubernetes, and self-managed environments.

This documentation corresponds to the latest patch available for each minor version. If you're not using the latest patch, check the release notes for changes.

Auditbeat Docker images can be used on Kubernetes to check files integrity.

Tip

Running Elastic Cloud on Kubernetes? See Run Beats on ECK.

Kubernetes deploy manifests for Auditbeat

By deploying Auditbeat as a DaemonSet we ensure we get a running instance on each node of the cluster.

Everything is deployed under kube-system namespace, you can change that by updating the YAML file.

To get the manifests just run:

Shell 
curl -L -O https://raw.githubusercontent.com/elastic/beats/9.5/deploy/kubernetes/auditbeat-kubernetes.yaml
Warning

If you are using Kubernetes 1.7 or earlier: Auditbeat uses a hostPath volume to persist internal data, it’s located under /var/lib/auditbeat-data. The manifest uses folder autocreation (DirectoryOrCreate), which was introduced in Kubernetes 1.8. You will need to remove type: DirectoryOrCreate from the manifest and create the host folder yourself.

Settings

Some parameters are exposed in the manifest to configure logs destination, by default they will use an existing Elasticsearch deploy if it’s present, but you may want to change that behavior, so just edit the YAML file and modify them:

YAML 
- name: ELASTICSEARCH_HOST
  value: elasticsearch
- name: ELASTICSEARCH_PORT
  value: "9200"
- name: ELASTICSEARCH_USERNAME
  value: elastic
- name: ELASTICSEARCH_PASSWORD
  value: changeme

Running Auditbeat on control plane nodes

Kubernetes control plane nodes can use taints to limit the workloads that can run on them. To run Auditbeat on control plane nodes you may need to update the Daemonset spec to include proper tolerations:

YAML 
spec:
 tolerations:
 - key: node-role.kubernetes.io/control-plane
   effect: NoSchedule

Deploy

To deploy Auditbeat to Kubernetes just run:

Shell 
kubectl create -f auditbeat-kubernetes.yaml

Then you should be able to check the status by running:

Shell 
$ kubectl --namespace=kube-system get ds/auditbeat

NAME       DESIRED   CURRENT   READY     UP-TO-DATE   AVAILABLE   NODE-SELECTOR   AGE
auditbeat   32        32        0         32           0           <none>          1m
Warning

Auditbeat is able to monitor the file integrity of files in pods, to do that, the directories with the container root file systems have to be mounted as volumes in the Auditbeat container. For example, containers executed with containerd have their root file systems under /run/containerd. The reference manifest contains an example of this.