Add Sematext Monitoring & Logging agents to trusted k8s containers

[megastef]

Please note
registry.access.redhat.com/sematext/agent,
registry.access.redhat.com/sematext/logagent
are not available yet, but we are in the process of certification ...

[megastef]

Please note that sematext/agent and sematext/logagent are now certified by RedHat and Docker. So please add the images to Falco rules.

Just published in RedHat registry:
https://access.redhat.com/containers/#/registry.connect.redhat.com/sematext/logagent
https://access.redhat.com/containers/#/registry.connect.redhat.com/sematext/agent

[fntlnz]

Hi @megastef - We are working on how to get this merged. Need more information to make sure we are on the same page on what are the the permissions needed by your images and wether this is ok or needs to change.

Adding the images to trusted_k8s_containers implies

• Create privileged pods
• Create Sensitive Mount Pod
• Create Hostnetwork Pod

For each one we need to understand why the three permissions are needed.

For example for sematext/sematext-agent-docker I see that the docker socket is needed https://github.com/sematext/sematext-agent-docker#quickstart and that is different from what you are proposing here, that container doesn't need Hostnetwork for instance.

Just need to clarify that kind of points for all the images you posted then we understand what changes are needed and we merge.

[megastef]

Hi,

Sematext Docker Agent will be replaced with sematext/agent and sematext/logagent.
https://sematext.com/blog/better-observability-new-container-agents/

1. Sematext Docker Agent could be limited to docker socket and directories like /var/logs.

2. Logagent might need access to docker socket and logs in /var/logs or access to containerd directories to collect logs or metadata via Kubernetes and Docker API. See e.g.: https://github.com/sematext/logagent-js/blob/master/kubernetes/ibm-cloud-logagent-ds.yml

3. Sematext Agent works very much like cAdvisor or sysdig agent, e.g. mounting several directories to collect system information, collecting information via eBPF kernel functions as well. It can also capture network packets for topology and network maps and might use pcap or eBPF for packet capture - so for network monitoring users can enable access to the host network.

docker run -d  --restart always --privileged -P --name st-agent \
-v /sys/kernel/debug:/sys/kernel/debug \
-v /var/run/:/var/run/ \
-v /proc:/host/proc:ro \
-v /etc:/host/etc:ro \
-v /sys:/host/sys:ro \
-v /usr/lib:/host/usr/lib:ro \
-e INFRA_TOKEN=<Infra App Token> \
-e CONTAINER_TOKEN=<Docker App Token> \
-e JOURNAL_DIR=/var/run/st-agent \
-e LOGGING_WRITE_EVENTS=false \
-e LOGGING_REQUEST_TRACKING=false \
-e LOGGING_LEVEL=info \
-e NODE_NAME=`hostname` \
-e CONTAINER_SKIP_BY_IMAGE=sematext \
sematext/agent:latest

I hope this helps.

[mstemm]

Ok, thanks. I think we'll want to eventually restructure our exceptions to have separate lists of images for individual capabilities like mounts, running privileged, etc. but for now, there's sufficient justification to add it.