Auditbeat running on host can't hash executable inside container - different namespaces

[xavigpich]

Describe the enhancement:
Auditbeat running on the host is auditing processes inside a Docker container. Auditbeat will hash an executable during the process enrichment even if that path is unreachable because it resides in a different namespace.

These expected errors are logged at WARN level. See below:

Jan 4 11:07:47 <hostname> auditbeat[16076]: 2021-12-17T11:07:47.857Z        WARN        [process]        process/process.go:249        failed to hash executable /usr/bin/python3.6 (deleted) for PID 1714: failed to stat file /usr/bin/python3.6 (deleted): stat /usr/bin/python3.6 (deleted): no such file or directory
Jan 4 11:07:47 <hostname> auditbeat[16076]: 2021-12-17T11:07:47.921Z        WARN        [process]        process/process.go:249        failed to hash executable /usr/lib/xorg/Xorg (deleted) for PID 2749: failed to stat file /usr/lib/xorg/Xorg (deleted): stat /usr/lib/xorg/Xorg (deleted): no such file or directory
Jan 4 11:08:02 <hostname> auditbeat[16076]: 2021-12-17T11:08:02.592Z        WARN        [process]        process/process.go:249        failed to hash executable /pause for PID 18534: failed to stat file /pause: stat /pause: no such file or directory

Haven't tried it, but Auditbeat running on a container might experience same errors on the OS namespace.

Describe a specific use case for the enhancement or feature:
Auditbeat hasher can recognize the audit event is originated in a container namespace and that it might not have access to it. In such cases, Auditbeat shouldn't try to hash the file - report on process metrics (#25777)

[elasticmachine]

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

[efd6]

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

[xavigpich]

Yeah, thanks for implementing the enhancement!