Hi Naruhiro,
well, if this had not been related to DOI, I would have. But since this is the metricbeat pod deployed from the doi_metricbeat image, I thought this was the right forum. Especially since I wanted to know of the experience other users of Broadcoms doi_metricbeat image has, and not the regular image.
But perhaps the lack of response is because I am the only one who has deployed self-monitoring on an on-premise solution with SELinux in enforcing mode?
It is my understanding the the metricbeat container needs to run in privileged mode. I question whether doi_metricbeat does that, and I am surprised that noone from Broadcom has responded!
Best regards
Olav
Original Message:
Sent: 02-04-2020 01:08 AM
From: NARUHIRO YONESHIGE
Subject: metricbeat and SElinux
Hi Olav,
I feel the topic would be better to submit "discuss.elastic.co" community.
I can see some similar discussion in there.
Best Regards,
Naruhiro
Original Message:
Sent: 02-03-2020 03:23 AM
From: Olav Tomte
Subject: metricbeat and SElinux
Am I the only one who sees this? I am running SELinux in enforcing mode, type targeted
Regards
Olav
Original Message:
Sent: 01-30-2020 03:58 AM
From: Olav Tomte
Subject: metricbeat and SElinux
Hi Nestor, wouldn't it be better to run metricbeat in privileged mode rather than changing file contexts in the /proc filesystem?
Olav
Original Message:
Sent: 01-30-2020 03:03 AM
From: NESTOR FALCON GONZALEZ
Subject: metricbeat and SElinux
Hi Olav, can you change the security context of the those folders?
chcon -Rt svirt_sandbox_file_t <folderpath>
Let us know
Nestor
Original Message:
Sent: 01-29-2020 10:28 AM
From: Olav Tomte
Subject: metricbeat and SElinux
Hi all,
after I deployed self-monitoring in my cluster, selinux is flooding my logs with messages like
SELinux is preventing /usr/bin/metricbeat from search access on directory 1
and similarly for all other directories in the /proc filesystem
and also
SELinux is preventing /usr/bin/metricbeat from connectto access on the unix_stream_socket /run/docker.sock
It is not enough to just change the acl on /var/run/docker.sock it seems. What is the best way to solve this?
thanks
Olav