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@lists.katacontainers.io Sent: Wednesday, April 14, 2021 4:42 AM To: Stefan Hajnoczi stefanha@redhat.com Cc: kata-dev kata-dev@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@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@lists.katacontainers.io http://lists.katacontainers.io/cgi-bin/mailman/listinfo/kata-dev