Open Stack

Eric,
 
Would your proposal allow open source projects like Minio which use S3 object storage to be able to directly access these from a Kata container without needing a host mount first? I've not used Minio but was just reading about it but below is their CSI driver for direct attach storage. 

https://github.com/minio/direct-csi

Thanks
Eric

-----Original Message-----
From: Peng Tao via kata-dev <kata-dev at lists.katacontainers.io> 
Sent: Wednesday, April 14, 2021 4:42 AM
To: Stefan Hajnoczi <stefanha at redhat.com>
Cc: kata-dev <kata-dev at lists.katacontainers.io>
Subject: Re: [kata-dev] RFC: direct-assigned filesystem volume proposal



On 2021/4/14 16:37, Stefan Hajnoczi wrote:
> On Wed, Apr 14, 2021 at 11:41:41AM +0800, Peng Tao wrote:
>> 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:
>>>
>>> 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.
> 
> If the host is already compromised then I don't expect Kata to protect 
> anything.
> 
> My question was about k8s persistent volumes. I wanted to check that 
> the csiPlugin.json file is not interpreted if present on a persistent 
> volume. It should only be interpreted when the CSI driver places it 
> there on the host. The text wasn't completely clear on whether the 
> "root of the volume on the host" refers to the contents of the 
> persistent volume itself (that's unsafe) or to the container runtime's 
> host path (that's safe).
> 

Ah, good point! Kata needs to differentiate between a PV containing a csiPlugin.json file in it, and a CSI driver "hacked" host path. They are both host directories from Kata's point of view.

A possible method is to check if the host path is a mountpoint. Then 1. do not ever try to parse the csiPlugin.json file if it is a mountpoint, and 2. require csi to ensure that the volume host directory is not a mountpoint (IOW do not mount the volume to the host directory)

wdyt?

Cheers,
Tao


_______________________________________________
kata-dev mailing list
kata-dev at lists.katacontainers.io
http://lists.katacontainers.io/cgi-bin/mailman/listinfo/kata-dev