Open Stack

Hi Tao and Eric,
Cc: my gmail


> I agree with the sentiment that privileged shouldn't be used unless
> actually necessary, which Akihirio showed isn't the case.
> FWICS, [2] doesn't work with runc, and is Kata specific?

[2] doesn't work with runc and is mostly specific to Kata.
Anyway [1] also seems specific to Kata, and doesn't seem to have any valid usecase with runc.

Regards,
Akihiro Suda

-----Original Message-----
From: eric.ernst at intel.com [mailto:eric.ernst at intel.com] 
Sent: Wednesday, September 18, 2019 1:09 AM
To: Peng Tao
Cc: kata-dev; Akihiro Suda; Xu Wang
Subject: Re: moby PRs for running DinD with kata

Hey Tao,

On Tue, Sep 17, 2019 at 11:42:20PM +0800, Peng Tao wrote:
> Hi Kata developers/maintainers/AC members,
> 
> Since I cannot attend the AC meeting today, I want to bring to your
> attention about two mody PRs([1] and [2]).

FWIW, I like using the ML for these kinds of discussions, anyway, since
it allows for more folks to chime in, and some digestion of the issue as
well.  Thanks for putting this on ML!

> 
> Akihiro Suda developed both of them as fixes for running DinD with
> kata (aka, docker in kata). [1] is to provide a new docker security
> option --privileged-without-host-devices, similar to the fix we had
> with containerd [1]. And [2] is to simply fix the DinD entrypoint.sh
> to remount sysfs in rw mode, and use a bunch of specific options to
> tell docker to give proper permissions to DinD container.

Thanks Akihiro.

> 
> While [2] is good enough to fix DinD with kata, I'm afraid there might
> be other container images out there that require similar tweaks to
> work.


I agree with the sentiment that privileged shouldn't be used unless
actually necessary, which Akihirio showed isn't the case.
FWICS, [2] doesn't work with runc, and is Kata specific?

This is probably fine for users who "know what they are doing," and
are running just in Kata? Maybe there should be a DiK or DinK image? 

> So I'd like to ask for your opinions on this. Do you think [2]
> is good enough or is it better to persuade moby maintainers to go with
> [1] instead?
>

I'm glad this is fixed already in containderd (and on its way for
cri-o). I think adding a new flag would be helpful for us, but I
understand this may not be acceptable from a moby maintainer pov.
Changing the behavior of existing is too difficult for end-users, and
i'm not sure an equivalent of [3] is feasilbe either.

What do others think?

-Eric



> Cheers,
> Tao
> 
> - [1] https://github.com/moby/moby/pull/39702
> - [2] https://github.com/docker-library/docker/pull/191
> - [3] https://github.com/containerd/cri/pull/1225
> 
> -- 
> Into something rich and strange.