sandbox: add support for shared directory for observability logs

[egernst]

We'd like to be able to reliably pull 'custom userspace application' logs from the Kata sandbox to facilitate getting event details out of the guest (imagine running something like auditd, or any other app...).

By creating a /var/log/kata/ directory on the host and bind mounting it to the host shared directory, we can provide a path that custom guest-userspace applications can leverage to provide logs onto the host, which could then be processed accordingly.

This path and mount is tied to the lifecycle of the sandbox, and is not exposed to the underlying container(s). Filesystem sharing is required for this.

Alternative considered: We looked at mimicking what is done with the agent traces, by sending application output over vsock onto the host. This requires a separate service running in the guest to forward this output, as well as at least one agent on the host to demux all of this. Similarly, it is painful since the vsock implementation varies per VMM configuration utilized.

todo:

• [ ] - make this configurable based on path in the config.toml

Signed-off-by: Eric Ernst eric.g.ernst@gmail.com

[liubin]

/cc @lifupan

[bergwolf]

@egernst where is the monitoring daemon running? Can it run in a container like a sidecar? Then all you need is to provide a host path volume for the container.

[egernst]

@bergwolf -- good question. The daemon is running as a service in the guest.

I had considered a sidecar as well, as it really does a nice job of giving me what I really want:

• running process in the guest
• artifacts necessary for the daemon can be applied via container rootfs, rather than baked into guest rootfs

• I get the logs I want already.

  The downsides that I couldn't overcome were: 1 ) ability to exec into this observability daemon. 2 ) Users would have visibility into the observability daemon (ie, kubectl get pod).

  I am treating this daemon as part of our infra, and don't want to expose end users to it.

[egernst]

I think this would be a large security liability, and require too much work on the host to look this path down for me to feel like this is a good idea at the point. Closing!