On 2021/4/12 22:46, Stefan Hajnoczi wrote:
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:
On Mon, Mar 29, 2021 at 04:49:31PM -0700, Eric Ernst 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
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.
+1, as a starter, we can try to make sure the initial API (or json) works for NFS and cifs IMHO.
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?
It is possible but it violates the current kata threat model, which is basically we'd have to trust the host. If a user is able to gain root privilege on the host, he/she is capable of doing anything to kata.
That said, it is indeed possible to mitigate this by using an RPC based approach between csi and kata.
Cheers, Tao