[ 
https://issues.apache.org/jira/browse/YARN-8376?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16792110#comment-16792110
 ] 

Eric Badger commented on YARN-8376:
-----------------------------------

bq. Eric Badger While I prefer the direct mapping, it is not backward 
compatible. There is already people using docker.trusted.registry to run 
privileged containers. This is shipped product in Hadoop 3.x. Hence, this 
option is not possible in Hadoop 3.x release. We can always wait until Hadoop 
4.x to commit this feature.

Yea that's true. While I still think that the approach I outlined above is more 
"correct", it is important to not break backwards compatibility. I retract my 
dissent on the approach for patch 2. I will review once [~Jim_Brennan] gives 
all of his comments. 

> Separate white list for docker.trusted.registries and 
> docker.privileged-container.registries
> --------------------------------------------------------------------------------------------
>
>                 Key: YARN-8376
>                 URL: https://issues.apache.org/jira/browse/YARN-8376
>             Project: Hadoop YARN
>          Issue Type: Sub-task
>            Reporter: Eric Yang
>            Assignee: Eric Yang
>            Priority: Major
>              Labels: docker
>         Attachments: YARN-8376.001.patch, YARN-8376.002.patch
>
>
> In the ideal world, it would be possible to have separate white lists for 
> docker registry depending on the security requirement for each type of docker 
> images:
> 1. Registries from which we can run non-privileged containers without mounts
> 2. Registries from which we can run non-privileged containers with mounts
> 3. Registries from which we can run privileged or non-privileged containers 
> with mounts
> In the current implementation, there are only type 1 and type 2 or 3.  It 
> would be nice to definite a separate white list to differentiate between 2 
> and 3.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to