[agentbeat] Fix agentbeat capabilities

[VihasMakwana]

Proposed commit message

• Allow agentbeat to elevate permissions to match the permitted set.
• These are required for non-root use to operate agent in healthy state.

Checklist

• My code follows the style guidelines of this project
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• I have made corresponding change to the default configuration files
• I have added tests that prove my fix is effective or that my feature works
• I have added an entry in CHANGELOG.next.asciidoc or CHANGELOG-developer.next.asciidoc.

Disruptive User Impact

How to test this PR locally

• https://github.com/elastic/elastic-agent/blob/main/docs/local-k8s-testing.md provides a good guide to test k8s locally.
• Clone the changes from this branch.
• Clone the changes from [docker][agentbeat]: add cap_sys_ptrace and cap_dac_override in permitted set elastic-agent#5271.
• Build a local docker image from elastic-agent.
• Install kind and create a cluster
• Run elastic-agent-standalone from elastic-agent repo.
• Make sure to use runAsUser: 1000 and add required capabilities in k8s manifest (SYS_PTRACE and DAC_OVERRIDE) like following:

securityContext:
  runAsUser: 1000
  privileged: false
  capabilities:
   add:
    - DAC_OVERRIDE
    - SYS_PTRACE
    - SETPCAP
    - CHOWN
   drop:
    - ALL

Related issues

• Relates [docker][agentbeat] - insufficient capabilities for agentbeat causes agent degradation elastic-agent#5269

Screenshots

Current behaviour, without enough capabilities:

Behaviour after the changes and elastic/elastic-agent#5271:

[mergify]

This pull request does not have a backport label.
If this is a bug or security fix, could you label this PR @VihasMakwana? 🙏.
For such, you'll need to label your PR with:

• The upcoming major version of the Elastic Stack
• The upcoming minor version of the Elastic Stack (if you're not pushing a breaking change)

To fixup this pull request, you need to add the backport labels for the needed
branches, such as:

• backport-v8./d.0 is the label to automatically backport to the 8./d branch. /d is the digit

[elasticmachine]

Pinging @elastic/elastic-agent-data-plane (Team:Elastic-Agent-Data-Plane)

[elasticmachine]

Pinging @elastic/elastic-agent-control-plane (Team:Elastic-Agent-Control-Plane)

[mergify]

This pull request is now in conflicts. Could you fix it? 🙏
To fixup this pull request, you can check out it locally. See documentation: https://help.github.com/articles/checking-out-pull-requests-locally/

git fetch upstream
git checkout -b fix-agentbeat-caps upstream/fix-agentbeat-caps
git merge upstream/main
git push upstream fix-agentbeat-caps

[cmacknz]

This entire block of code is Linux specific, you don't need to also duplicate the Windows and MacOS HasRoot implementations. You can just make the implementation of initCapabilities a no-op on those OSes instead.

If we want to share HasRoot put them in elastic-agent-libs, the implementation particularly for Windows is non-trivial and has had bugs recently.

[VihasMakwana]

I've removed it for other OSes.
Can you take a look?

[blakerouse]

I do not believe this should have been merged this way. Overall setting capabilities is not an agentbeat specific thing, it should be set per beat type and only for the types that the specific beat needs. This seems to just be a promote all from from effective and inheritable to the permitted set, from a security perspective this is not great. It should be limiting to only what each beat type needs. Agentbeat itself is not a beat it is a metabeat and should not be in-charge of this work directly.

I also feel like merging this as is, was not the correct thing todo. We have similar logic in Elastic Agent and this needs to be moved to each individual beat so this code should be moved to a generic location first, and not merged to then be moved later. We should strive for cleanliness even if it delays the merge some time. It would also be interesting to know if OTEL already has something like this? If so is it in a library that could be re-used? If not does another library already exist that can be re-used or should be make our own module for this specific logic?

I had been thinking about this PR over the weekend, I was not expecting it to be merged so quickly.

[pkoutsovasilis]

I did an experiment and reverted this PR as in my thinking it shouldn't be necessary for this code to exist in agentbeat. This is because elastic-agent, after merging this PR, when running rootless is raising all capabilities from Bounding set (specified in k8s manifest) to it's Ambient set to allow subprocesses maintain them. As shown below k8s tests with this PR and without the code here are running without failures