Unable to start Auditbeat container on Docker


#1

I have tried this in both CentOS 7 and RHEL Atomic Host. Using ansible, I use the following, with the params containing valid values:

docker_container:
name: auditbeat
image: "{{ auditbeat_image }}:{{ auditbeat_version }}"
hostname: "{{ ansible_fqdn }}"
pull: yes
state: started
volumes: "{{ auditbeat_all_volumes }}"
privileged: true
pid_mode: host
command: auditbeat -e -c /etc/auditbeat/auditbeat.yml

And end up with:

[centos@beats-anha-node2 ~]$ sudo docker logs -f auditbeat
2018-02-26T11:54:17.466Z	INFO	instance/beat.go:468	Home path            [/usr/share/auditbeat] Config path: [/usr/share/auditbeat] Data path:    [/usr/share/auditbeat/data] Logs path: [/usr/share/auditbeat/logs]
2018-02-26T11:54:17.473Z	INFO	instance/beat.go:475	Beat UUID: 2a85d2d2- 19ef-45c0-90d9-8e80492144d6
2018-02-26T11:54:17.473Z	INFO	instance/beat.go:213	Setup Beat: auditbeat; Version: 6.2.2
2018-02-26T11:54:17.474Z	INFO	fileout/file.go:76	Initialized file output. path=/tmp/auditbeat/output max_size_bytes=10485760 max_backups=7 permissions=-rw-------
2018-02-26T11:54:17.474Z	INFO	pipeline/module.go:76	Beat name: beats-anha-node2.beans.io
2018-02-26T11:54:17.476Z	INFO	[auditd]	auditd/audit_linux.go:65	auditd module is running as euid=0 on kernel=3.10.0-693.11.6.el7.x86_64
2018-02-26T11:54:17.477Z	ERROR	instance/beat.go:667	Exiting: 1 error: 1 error: failed to create audit client: failed to get audit status: failed sending request: connection refused

Using the following config(generated from yaml):

[centos@beats-anha-node2 ~]$ cat /etc/auditbeat/auditbeat.yml 
auditbeat.modules:
- {audit_rules: '-a always,exit -F arch=b32 -S all -F key=32bit-abi

-a always,exit -F arch=b64 -S execve,execveat -k exec

-a always,exit -F arch=b64 -S accept,bind,connect -F key=external-access

-w /etc/group -p wa -k identity

-w /etc/passwd -p wa -k identity

-w /etc/gshadow -p wa -k identity

-a always,exit -F arch=b64 -S     open,creat,truncate,ftruncate,openat,open_by_handle_at
-F exit=-EACCES -k access

-a always,exit -F arch=b64 -S open,creat,truncate,ftruncate,openat,open_by_handle_at
-F exit=-EPERM -k access

', backlog_limit: 8196, failure_mode: silent, module: auditd, rate_limit: 0, resolve_ids: true}
- module: file_integrity
paths: [/bin, /usr/bin, /sbin, /usr/sbin, /etc]
name: beats-anha-node2.beans.io 
output.file: {enable: true, filename: output, path: /tmp/auditbeat}
processors: {add_cloud_metadata: null, add_docker_metadata: null, add_locale:     null}

I saw that Luq had the same error in his log.Luq's Thread Since I run as privileged, and using pid_mode: host I was thinking it should work.


#2

Trying to follow Running on Docker using a config I have created from yaml for my native installation of Auditbeat, which works perfectly.

[centos@beats-anha-node1 ~]$ sudo docker run --pid=host -v      /etc/auditbeat/auditbeat.yml:/usr/share/auditbeat/auditbeat.yml docker.elastic.co/beats/auditbeat:6.2.2
2018-02-27T15:05:52.954Z	INFO	instance/beat.go:468	Home path: [/usr/share/auditbeat] Config path: [/usr/share/auditbeat] Data path: [/usr/share/auditbeat/data] Logs path: [/usr/share/auditbeat/logs]
2018-02-27T15:05:52.957Z	INFO	instance/beat.go:475	Beat UUID: 8422f1ad-bdd6-4c84-bf38-41a85fc4d2d8
2018-02-27T15:05:52.957Z	INFO	instance/beat.go:213	Setup Beat: auditbeat; Version: 6.2.2
2018-02-27T15:05:55.958Z	INFO	add_cloud_metadata/add_cloud_metadata.go:297	add_cloud_metadata: hosting provider type not detected.
2018-02-27T15:05:55.959Z	ERROR	instance/beat.go:667	Exiting: error initializing publisher: error initializing processors: Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running?
Exiting: error initializing publisher: error initializing processors: Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running?
[centos@beats-anha-node1 ~]$ cat /etc/auditbeat/auditbeat.yml
auditbeat.modules:
- {audit_rules: '-a always,exit -F arch=b32 -S all -F key=32bit-abi

-a always,exit -F arch=b64 -S execve,execveat -k exec

-a always,exit -F arch=b64 -S accept,bind,connect -F key=external-access

-w /etc/group -p wa -k identity

-w /etc/passwd -p wa -k identity

-w /etc/gshadow -p wa -k identity

-a always,exit -F arch=b64 -S     open,creat,truncate,ftruncate,openat,open_by_handle_at
-F exit=-EACCES -k access

-a always,exit -F arch=b64 -S open,creat,truncate,ftruncate,openat,open_by_handle_at
-F exit=-EPERM -k access

', backlog_limit: 8196, failure_mode: silent, module: auditd, rate_limit: 0, resolve_ids:  true}
- module: file_integrity
paths: [/bin, /usr/bin, /sbin, /usr/sbin, /etc]
name: beats-anha-node1.beans.io
output.file: {enable: true, filename: output, path: /tmp/auditbeat}
processors:
- {add_cloud_metadata: null}
- {add_locale: null}
- {add_docker_metadata: null}

My docker-colleague asks out loudly why Auditbeat inside the container would want to talk to the Docker daemon?


(Andrew Kroh) #3

Is this a docker-compose config you are showing above? If so, pid_mode doesn't look correct. Here's an example for Auditbeat: https://github.com/elastic/stack-docker/blob/3fb05538483c94bd0bd9bd480bb5c0cfd1f8df79/docker-compose.yml#L48-L56

This is because you have configured the add_docker_metadata processor. This processor connects to socket to receive docker events. It then uses this information to enrich events with information about the associated container. For example if an execve happens inside a container then the event will have the container id, name, and labels.


#4

The above is just an ansible-task starting up a docker container, using the syntax from http://docs.ansible.com/ansible/latest/docker_container_module.html#docker-container

Ahh, ok, I was playing around with the config, but I can see how that would cause Auditbeat to want to ask docker stuff..

I will clean up the conf and try again.