[Agent] Minimizing Elastic-Agent privileges

[andrewvc]

Action plan after meeting today with @blakerouse @fntlnz and @justinkambic

There are three use cases for elastic-agent with different security requirements, where we can have three different behaviors.

For docker containers specifically, we need a clear path to running as non-root for two reasons:

1. It will be flagged by many orgs as insecure,
2. Some software (synthetics) cannot run as root, so we need consistent guidance, today we need to advise people to run as different users for different use cases.

New Behavior by Use Case

Install command on local machine

1. Keep running as root
2. Individual beats can downgrade privileges / setuid as needed (see [Heartbeat] Setuid to regular user / lower capabilities when possible beats#27878 which does this in just heartbeat as an example)

Run in docker with docker run

1. No need to run as root because we don't run elastic endpoint security, we should recommend running as elastic-agent
2. We will need to use setcap to add privileges to the elastic-agent binary
3. Individual beats should downgrade privileges via setcap as needed
4. If you want to run endpoint then you'll need to run a separate container with

docker run --network agent elastic-agent
docker run --network agent --privileged elastic-endpoint

Run in kubernetes

1. Run a pod for agent that contains an unprivileged container for elastic-agent, and a privileged container for elastic-endpoint

Tasks:

• Elastic-agent docs updated to recommend running as regular user
• Use setcap in elastic-agent docker container to add all required capabilities as inheritable so subprocesses can use privs
• Modify individual beats to setuid / setcap/ downgrade for the local machine use case
  • Use setcap in subprocesses in container to drop unneeded privileges