auditbeat doesn't recognize that a path in an audit record might be in an inaccessible namespace.

[barrylustig]

Describe the enhancement:
auditbeat will blindly try and hash an executable during process enrichment (func (ms *MetricSet) enrichProcess(process *Process)) even if that path is unreachable because it resides in a different namespace. For example, auditbeat gets an audit record for an exec that occurs inside a container. The exec is for a file path that only resides inside the container. Auditbeat, running on the host, tries to hash the file. It will always fail the os.Stat call and log and error at the warning level. It would be useful for auditbeat to recognize that the audit record is coming from a container and that it might not have access to that namespace.

Describe a specific use case for the enhancement or feature:
Eliminate a number of unnecessary function calls, a stat failure and an extraneous log message. As it is now, we have to set auditbeat's logging level to error, so that we don't swamp our system logs.

[elasticmachine]

Pinging @elastic/security-external-integrations (Team:Security-External Integrations)

[barrylustig]

I think this could be easily address if "enrichProcess" has info that the record comes from a container, then the failed stat call might be better logged at the debug level. It should only be a warning if there is an expectation that the file exists in the host namespace.

[efd6]

@barrylustig are you happy that #29786 has fixed this for you?

[botelastic]

Hi!
We just realized that we haven't looked into this issue in a while. We're sorry!

We're labeling this issue as Stale to make it hit our filters and make sure we get back to it as soon as possible. In the meantime, it'd be extremely helpful if you could take a look at it as well and confirm its relevance. A simple comment with a nice emoji will be enough :+1.
Thank you for your contribution!