Open Stack

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 at 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.

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.katacontainers.io/pipermail/kata-dev/attachments/20210412/2d94af08/attachment.sig>