On Wed, Apr 07, 2021 at 05:07:05PM -0700, Eric Ernst wrote:
On Thu, Apr 1, 2021 at 7:58 AM Stefan Hajnoczi <stefanha@redhat.com> wrote:
I'd like to see if we can create a pattern in upstream Kata Containers to help facilitate directly assigning volumes to the VM via virtio-blk, skipping any mounts on the host, and avoiding needing to use a shared file-system for the particular volume. Some of the benefits in doing
On Mon, Mar 29, 2021 at 04:49:31PM -0700, Eric Ernst wrote: this:
- we can better isolate the host (no mounted filesystem),
It would be nice to make the mechanism extensible so other types of volumes can be attached in the future.
It might be desirable to perform an NFS mount inside the sandbox VM instead of on the host, for example. The downside is that the sandbox VM needs access to the storage network, but the host kernel is no longer involved.
Stefan,
Sorry I missed this initial reply. Can you help with identifying how you think we should augment the DiskMountInfo structure to accomodate?
DiskMountInfo supports common mount(1) parameters. This looks fine. I'm not familiar enough with various storage providers (e.g. GlusterFS) to say if anything is missing. I think it's worth keeping non-block device use cases in mind from the start just to avoid implementing the feature in a way that limits it to attaching block devices. BTW, one aspect of the draft that isn't clear to me: the CSI driver will create a particular file, csiPlugin.json at the root of the volume on the host Can a malicious user put a csiPlugin.json file onto a persistent volume and then attach it to a Kata-enabled container to get the runtime and/or agent to execute mount commands either on the host or in the sandbox VM? Stefan