Containerd versions v1.3+ have support for log plugins, where a task is configured with the path to an external binary and the shim will invoke that binary to handle persisting log data. This functionality is roughly equivalent to Docker's logging drivers (https://docs.docker.com/config/containers/logging/plugins/).

The CRI plugin currently bypasses Containerd's log plugins, writing logs only to disk in a format and location determined by the Kubelet. This makes it difficult to use Containerd as the runtime for Kubernetes in a cluster where we want more precise control over log data.

Example policies that a custom log plugin might enforce include:

• Log data is pre-processed to remove potentially sensitive information (e.g. via https://github.com/stripe/unilog)
• Pre-processed log data is not allowed to be written to persistent disk.
• Log lines may be persisted to remote storage at different sampling levels depending on content.

From a bit of digging into the CRI plugin I believe support for log plugins could be added into pkg/server/io/container_io.go or pkg/server/container_start.go, with the log plugin taking the place of ContainerdIO as a containerdio.Creator. Does this sound reasonable? I would be willing to implement support for this and shepherd it upstream if the CRI plugin maintainers are open to the idea.