Open Stack

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