Support running Auditbeat and Elastic Agent docker images without root

[jsoriano]

In general it makes more sense to run Auditbeat and Elastic Agent as root. Most of Auditbeat functionality requires high privileges, and Elastic Agent has capabilities to start and supervise other services, including Auditbeat, so it also requires these privileges. Endpoint probably also require high privileges.

For that, docker images use USER root, but this goes against generally accepted good practices, containers run with arbitrary user ids in secured Kubernetes environments, and Red Hat certified images cannot run as root.

So we should stop using USER root, at least in UBI images, that are more intended to certified, secure environments. We have to take into account that the images could still be run as root in privileged environments with runtime options.

Things to do:

• Remove USER root from Auditbeat and Elastic Agent docker images (at least from the UBI ones).
• Ensure that they include a minimal configuration that provides some functionality without root privileges. If this is not possible, we will have to reconsider this.
• Ensure that they can still be run as root, with specific runtime options for that, in privileged environments.

Where to look at:

• User is set to root for Auditbeat in the magefile.go (here), if we are going to provide different config for default and UBI images, we will have to move this to the packages.yml file as a new config that extends common Beats config, what would allow a cleaner override.
• User is set to root for Elastic Agent in the packages.yml file (here).

Related PRs and issues:

• UBI images - Build docker images based on Red Hat UBI #20576
• Support running containers with arbitrary users - Allow the Docker image to be run with a random user id (#12905) #18873
• Improving support on restricted environments - Improve support of Beats on Kubernetes restricted environments #19600

[elasticmachine]

Pinging @elastic/integrations-platforms (Team:Platforms)

[elasticmachine]

Pinging @elastic/ingest-management (Team:Ingest Management)

[elasticmachine]

Pinging @elastic/siem (Team:SIEM)

[ph]

@blakerouse Can you do a follow up with @jsoriano on the required changes for the Elastic Agent?

[ph]

@jsoriano Do Packetbeat have the same problems?

[jsoriano]

@jsoriano Do Packetbeat have the same problems?

Nop, it is not using USER root.

Though it doesn't start unless --privileged is used 🤔

$ docker run -it --rm  docker.elastic.co/beats/packetbeat:7.9.0
/usr/local/bin/docker-entrypoint: line 8: /usr/share/packetbeat/packetbeat: Operation not permitted

We should find a consistent solution for containers requiring privileges.

[jsoriano]

I have created a separated issue for Packetbeat as the problem is different: #21032

[blakerouse]

I think from Elastic Agent side, it's not required for it to be ROOT. But I do think we need to ensure we disable Endpoint when not running as ROOT, also we probably need to ensure it doesn't run when in a container anyway.

[jsoriano]

I think from Elastic Agent side, it's not required for it to be ROOT. But I do think we need to ensure we disable Endpoint when not running as ROOT, also we probably need to ensure it doesn't run when in a container anyway.

I think it is enough if the container starts with the default configuration, and it fails later depending on some custom configuration or some other condition. It is in principle ok to give more privileges on runtime (with --cap-add, --privileged...).

I will give a try to just removing USER root, and check if privileged features work with the same image after adding privileges.

[jsoriano]

I am closing this after reviewing/fixing these cases:

• Auditbeat fails with default configuration if run without root user, but also if run without other privileges, so USER root only doesn't help. All this is documented and I remove USER root in Cherry-pick #21175 to 7.x: Some fixes in Cloud Foundry fields #21201.
• Elastic Agent can start filebeat and metricbeat with the default configuration without the need of USER root. Some services services or features will need additional capabilities to work correctly, but only USER root doesn't help on that, similar to the Auditbeat case. I remove USER root and make some adjustements so it works in Stop running agent container as root by default #21213.
• Packetbeat requires NET_ADMIN capabilities to work, and this is documented. USER root doesn't help because it is not enough to provide this capability, and is already not used, so nothing to do.