[
https://issues.apache.org/jira/browse/YARN-8342?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16493990#comment-16493990
]
Eric Badger commented on YARN-8342:
-----------------------------------
bq. Sudo users can easily change the configuration to allow the untrusted
registry to become trusted. It would be very difficult to prevent sudo users
from untrusted registries. This is a procedure problem rather than coding
problem.
Certainly. If the user is a sudo user then they would be able to change the
configuration. Again, my idea behind this is to decrease the potential attack
surface. More to give a user an easy way to run an untrusted image with a
smaller scope. If they truly wanted to run the image full-bore, then they
absolutely could. For example, I could want to try out some random image from
dockerhub that isn't trusted to me at all. Therefore, I don't want to run it in
the same way in which I run images from my trusted internal registry with
trusted and audited images.
bq. Let's make sure we agree on the required code fix. If
docker.privileged-containers.enabled is disabled, and user put images in
docker.trusted.registries. The images in docker.trusted.registries behaves like
type 2. When docker.privileged-containers.enabled is enabled, and user put
images in docker.trusted.registries, images behaves like type 3. Registries not
described in trusted registries are type 1 regardless of
docker.privileged-containers.enabled setting. Hence, the
docker.privileged-container.registries renamed to docker.trusted.registries can
address the confusion.
Yes, for a single registry this would work. However, the use case is when you
have multiple different registries that you would like to treat differently. If
you have a single docker.trusted.registries list, then either all or none of
the registries that you add to docker.trusted.registries support privileged
containers. However, there could be a separation between the two. For example,
there could be a company-wide registry that is "trusted", but you don't trust
it enough to run those images as privileged. Then, you have your own
team-specific registry that is trusted and is heavily audited by your team. You
have high confidence in everything in this registry and therefore are willing
to let these images be run as privileged. With a single list for registries
(with mounts), I believe this use case would be impossible.
bq. This JIRA is going to tweak type 1 to allow launch_command to be supplied
and change docker.privilegd-containers.registries label. Do we agree this is
the right safety valves and changes that are going to happen?
I agree with the launch_command change. As for the registries label change, it
would be nice to have a plan in place for how we're going to tackle this to
make it less confusing. However, I'm also ok making that a separate change in a
different JIRA.
bq. Eric Badger Btw, docker.privileged-containers.enabled is a
container-executor.cfg property, not a user supplied setting. Is this how it is
enforced on your side?
Yes, privileged containers as a whole are enabled/disabled based on a
container-executor.cfg property. However, asking for them is specified by the
user.
> Using docker image from a non-privileged registry, the launch_command is not
> honored
> ------------------------------------------------------------------------------------
>
> Key: YARN-8342
> URL: https://issues.apache.org/jira/browse/YARN-8342
> Project: Hadoop YARN
> Issue Type: Sub-task
> Reporter: Wangda Tan
> Assignee: Eric Yang
> Priority: Critical
> Labels: Docker
> Attachments: YARN-8342.001.patch
>
>
> During test of the Docker feature, I found that if a container comes from
> non-privileged docker registry, the specified launch command will be ignored.
> Container will success without any log, which is very confusing to end users.
> And this behavior is inconsistent to containers from privileged docker
> registries.
> cc: [~eyang], [[email protected]], [~ebadger], [~jlowe]
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
