[ https://issues.apache.org/jira/browse/YARN-5534?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16255681#comment-16255681 ]
Shane Kumpf edited comment on YARN-5534 at 11/16/17 5:45 PM: ------------------------------------------------------------- {quote} We can check the origin of the docker image, if it comes from private registry, image name that starts with hostname of private registry, then we allow white list volumes. {quote} IMO the hosted docker private repositories should be allowed. Checking that the image isn't from docker.io would be problematic for that case. The docker hub private repository solution gives users a private space to store images without needing to manage the private registry infrastructure themselves. Using the docker hub private repositories also gives the user vulnerability scanning "for free", so it's appealing to new users where pull bandwidth isn't of major concern. IMO, this is a pretty safe alternative to running your own private registry. As [~ebadger] mentioned, there are other items that need to change to support these types of images beyond the whitelist; don't override the CMD/ENTRYPOINT, don't bind mount the container log dir, usercache, appcache, don't override the --user option, etc. I would prefer if we worked through those details holistically on a separate JIRA and see if it's even necessary to support that use case. was (Author: shaneku...@gmail.com): {code} We can check the origin of the docker image, if it comes from private registry, image name that starts with hostname of private registry, then we allow white list volumes. {code} IMO the hosted docker private repositories should be allowed. Checking that the image isn't from docker.io would be problematic for that case. The docker hub private repository solution gives users a private space to store images without needing to manage the private registry infrastructure themselves. Using the docker hub private repositories also gives the user vulnerability scanning "for free", so it's appealing to new users where pull bandwidth isn't of major concern. IMO, this is a pretty safe alternative to running your own private registry. As [~ebadger] mentioned, there are other items that need to change to support these types of images beyond the whitelist; don't override the CMD/ENTRYPOINT, don't bind mount the container log dir, usercache, appcache, don't override the --user option, etc. I would prefer if we worked through those details holistically on a separate JIRA and see if it's even necessary to support that use case. > Allow whitelisted volume mounts > -------------------------------- > > Key: YARN-5534 > URL: https://issues.apache.org/jira/browse/YARN-5534 > Project: Hadoop YARN > Issue Type: Sub-task > Components: yarn > Reporter: luhuichun > Assignee: Shane Kumpf > Attachments: YARN-5534.001.patch, YARN-5534.002.patch, > YARN-5534.003.patch > > > Introduction > Mounting files or directories from the host is one way of passing > configuration and other information into a docker container. > We could allow the user to set a list of mounts in the environment of > ContainerLaunchContext (e.g. /dir1:/targetdir1,/dir2:/targetdir2). > These would be mounted read-only to the specified target locations. This has > been resolved in YARN-4595 > 2.Problem Definition > Bug mounting arbitrary volumes into a Docker container can be a security risk. > 3.Possible solutions > one approach to provide safe mounts is to allow the cluster administrator to > configure a set of parent directories as white list mounting directories. > Add a property named yarn.nodemanager.volume-mounts.white-list, when > container executor do mount checking, only the allowed directories or > sub-directories can be mounted. -- This message was sent by Atlassian JIRA (v6.4.14#64029) --------------------------------------------------------------------- To unsubscribe, e-mail: yarn-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: yarn-issues-h...@hadoop.apache.org