Jeffrey I'm not certain I agree with the security logic. It rather reduces some of the deployment use-cases (and hence the potential economic value).
There are several scenarios where you want the security information _inside_ the ‘container', this makes the container (say a VM of some kind) more mobile. It also depends on the trust structure - it is not always going to be the case that the outer system is deemed more privileged that the inner one - telco’s are looking to “sell” containers in their networks (part of NFV) in that case you would want your container to hold the secret information. Neil On 28 Nov 2015, at 21:58, Jeffrey Altman <jalt...@auristor.com> wrote: > On 11/28/2015 4:19 PM, Neil Davies wrote: >> I can confirm that this sis the problem >> >> There was a change in docker 1.2.1 (a CVE related fix) that now forces >> /proc/fs to be mounted read-only >> >> use of the --privileged argument to docker run does allow openafs to run >> ok, but only at the cost of loosing >> all of the container isolation! >> >> I spent some time trying to work out how to _just_ permit read-write access >> to the appropriate portion of >> the /proc/fs filestore, but not cracked it. >> >> It is potentially possible to mount the host's /proc/fs/openafs under a >> different name (with read-write access) >> within the container - but that would imply a change to the openafs building >> process.... >> >> Obviously I could modify the docker sources, submit a patch etc.. >> >> Any suggestions? I'm just wondering if there is any other bits of >> functionality that the docker folks might have >> broken this way - looking to see if there we, as a community, are not alone >> here. >> >> Neil > > Containers were not designed with the expectation that they would be > accessing resources from a network file system. > > The solution that I am pursuing with Microsoft is to permit the > container to be created with a network identity associated to it. > For Linux what we would want is the ability to start a container and all > of its processes as part of a PAG where a process running in the host > context (not the container's) would obtain the tokens for the container. > > I believe it is inappropriate for the container processes to have access > to a keytab or a username/password combination. > > I agree with Microsoft that a container should not be able to modify > kernel driver state such as by storing a network credential for a remote > user. There is no requirement that kernel drivers provide security > boundaries between container name spaces. > > There are some use cases such as running an sshd that provides shells > with access to network resources as the remote user identity which are > not appropriate for Containers. Virtual machines should be used in such > instances to obtain the proper process isolation. > > Jeffrey Altman > > > <jaltman.vcf> _______________________________________________ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
