Bug 1415805 - docker v1.12.5 missing auth plugin for policy.json
Summary: docker v1.12.5 missing auth plugin for policy.json
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: docker
Version: 7.3
Hardware: Unspecified
OS: Linux
unspecified
medium
Target Milestone: rc
: ---
Assignee: Lokesh Mandvekar
QA Contact: atomic-bugs@redhat.com
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-01-23 19:07 UTC by Aaron Weitekamp
Modified: 2019-03-06 00:55 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-01-25 18:59:38 UTC
Target Upstream Version:


Attachments (Terms of Use)

Description Aaron Weitekamp 2017-01-23 19:07:15 UTC
Description of problem:
docker-latest has an auth plugin to verify image signatures during pull. docker 12.5 is missing this capability. It's unexpected to have difference in security behavior.

Version-Release number of selected component (if applicable):
12.5

How reproducible:
always

Steps to Reproduce:
1. atomic trust default reject
2. docker pull ANY_IMAGE

Actual results:
Image is pulled to docker daemon

Expected results:
Image pull should be rejected by policy

Additional info:

$ sudo atomic trust default reject
$ sudo atomic trust show
* (default)                         reject
$ sudo atomic pull docker.io/library/busybox:latest
Image docker.io/library/busybox:latest is being pulled to docker ...
Pulling docker.io/library/busybox:latest ...
FATA[0000] Source image rejected: Running image docker://busybox:latest is rejected by policy.

$ sudo docker pull docker.io/library/busybox:latest
Trying to pull repository docker.io/library/busybox ...
latest: Pulling from docker.io/library/busybox
4b0bc1c4050b: Pull complete
Digest: sha256:817a12c32a39bbe394944ba49de563e085f1d3c5266eb8e9723256bc4448680e

$ cat /etc/redhat-release
Red Hat Enterprise Linux Server release 7.3 (Maipo)
$ sudo docker version
Client:
 Version:         1.12.5
 API version:     1.24
 Package version: docker-common-1.12.5-14.el7.x86_64
 Go version:      go1.7.4
 Git commit:      047e51b/1.12.5
 Built:           Wed Jan 11 17:53:20 2017
 OS/Arch:         linux/amd64

Server:
 Version:         1.12.5
 API version:     1.24
 Package version: docker-common-1.12.5-14.el7.x86_64
 Go version:      go1.7.4
 Git commit:      047e51b/1.12.5
 Built:           Wed Jan 11 17:53:20 2017
 OS/Arch:         linux/amd64
$ sudo atomic -v
1.14.1

Comment 1 Lokesh Mandvekar 2017-01-23 19:44:33 UTC
Hi Aaron, so docker and docker-latest currently on RHEL are using the same projectatomic/docker-1.12.5 branch. Speaking from the rpm side, there should be no difference in behavior unless of course, packaging errors on my part.

There's no additional auth plugin being used (correct me if I read your comment wrong).

Also, I see that I'm able to pull using both docker and docker-latest. But if I try to pull via atomic, it gets rejected.

Could you confirm the pull gets rejected when you use docker-latest? It's hard to tell from the description above.

Comment 2 Aaron Weitekamp 2017-01-23 20:55:18 UTC
It turns out docker and docker-latest both are running v1.12.5. So it appears the auth plugin isn't enabled or something with either docker package. This may be operator error not knowing how to configure docker to enforce policy.json. Please advise.

Comment 3 Antonio Murdaca 2017-01-24 08:06:55 UTC
(In reply to Aaron Weitekamp from comment #2)
> It turns out docker and docker-latest both are running v1.12.5. So it
> appears the auth plugin isn't enabled or something with either docker
> package. This may be operator error not knowing how to configure docker to
> enforce policy.json. Please advise.

which auth plugin are we talking about here? There should be no auth plugin anymore. We have embedded signatures verification for image pulling directly into docker. If something isn't working it shouldn't be because of any plugin. I'll take  a look at this.

Comment 4 Antonio Murdaca 2017-01-24 10:58:09 UTC
Figured this out. The thing is we're running docker (and docker-latest) with "--signature-verification=false" by default (since it breaks OpenShift backward compatibility otherwise) and that means "docker pull" does not verify against the policy _at all_.
You can try to turn that flag to "true" and effectively notice that if your policy has a default of reject, you can't pull anything.
Atomic behaves differently because signature verification is enabled by default and there's no knob to disable it.
Re-stating, turning the flag to "false" was a specific request from OpenShift.

Comment 6 Aaron Weitekamp 2017-01-24 21:00:45 UTC
I verified this docker options setting does work. I added "--signature-verification=true" to /etc/sysconfig/docker. For example:

OPTIONS='--selinux-enabled --log-driver=journald --signature-verification=true'

Restarted docker.service

$ sudo docker pull docker.io/library/busybox:latest
Trying to pull repository docker.io/library/busybox ...
docker.io/busybox:latest isn't allowed: Running image docker://busybox:latest is rejected by policy.

Comment 7 Aaron Weitekamp 2017-01-25 16:12:13 UTC
I suggest adding a self-documenting config option so the user can see that there's a knob to turn this on.

PATCH
commit 715e939ab2df5c84a501b00233a9c03613b994e8
Author: Aaron Weitekamp <aweiteka@redhat.com>
Date:   Wed Jan 25 10:45:01 2017 -0500

    add signature-verification to sysconfig docker

diff --git a/contrib/init/systemd/docker b/contrib/init/systemd/docker
index bcdeca6..09d3990 100644
--- a/contrib/init/systemd/docker
+++ b/contrib/init/systemd/docker
@@ -1,7 +1,7 @@
 # /etc/sysconfig/docker

 # Modify these options if you want to change the way the docker daemon runs
-OPTIONS='--selinux-enabled --log-driver=journald'
+OPTIONS='--selinux-enabled --log-driver=journald --signature-verification=false'
 DOCKER_CERT_PATH=/etc/docker

 # If you want to add your own registry to be used for docker search and docker

Comment 8 Antonio Murdaca 2017-01-25 16:36:38 UTC
Well, we can surely do that in rhel, Lokesh could you apply Aaron's patch to rhel configuration in dist-git?

Comment 9 Lokesh Mandvekar 2017-01-25 18:11:54 UTC
(In reply to Antonio Murdaca from comment #8)
> Well, we can surely do that in rhel, Lokesh could you apply Aaron's patch to
> rhel configuration in dist-git?

yup, that's why I asked Aaron to reopen it. adding it..

Comment 10 Aaron Weitekamp 2017-01-25 18:59:38 UTC
It turns out this is already in the updated installed config exactly as the proposed patch.


Note You need to log in before you can comment on or make changes to this bug.