Bug 1398711 - Image pushed to the internal docker registry by a user can be pulled by any other user without being authorized
Summary: Image pushed to the internal docker registry by a user can be pulled by any o...
Keywords:
Status: CLOSED WORKSFORME
Alias: None
Product: OpenShift Container Platform
Classification: Red Hat
Component: Image Registry
Version: 3.3.0
Hardware: Unspecified
OS: Unspecified
low
low
Target Milestone: ---
: ---
Assignee: Michal Minar
QA Contact: Wei Sun
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-11-25 16:21 UTC by Miheer Salunke
Modified: 2020-02-14 18:12 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-11-06 23:23:55 UTC
Target Upstream Version:


Attachments (Terms of Use)

Description Miheer Salunke 2016-11-25 16:21:03 UTC
Description of problem:

Image pushed to the internal docker registry by a user can be pulled by any other user without being explicitly authorized by the user that pushed the image. I would expect that images created and pushed in project 1 by user 1 are not visible in project 2 by user 2 unless user 1 explicitly authorizes user 2 or unless user 2 is cluster admin.


Version-Release number of selected component (if applicable):
Openshift Container Platform v3.3 installed using the quick installation mode. Using the internal docker-registry which is installed "out-of-the-box".

How reproducible:
Customer side

Steps to Reproduce:
1.Openshift Container Platform v3.3 installed using the quick installation mode. Using the internal docker-registry which is installed "out-of-the-box".
2) Create two default users: user I and user II
3) Add the username/password for both users to the attached script
4) Run the script

Actual results:

After running the script. User 1 created an image in it's own project, which can be pulled and deployed by User 2 in a different project. Both projects are not visible for one other.

Expected results:


Additional info:

Comment 2 Michal Minar 2016-11-29 11:43:46 UTC
So far I wasn't able to reproduce using latest 3.3 version:

    $ oc version
    oc v3.3.1.4+2aa5a41-dirty
    kubernetes v1.3.0+52492b4
    features: Basic-Auth

    Server https://192.168.122.82:8443
    openshift v3.3.1.4+2aa5a41-dirty
    kubernetes v1.3.0+52492b4

Here's what I see at the end of execution of docker-image-right-test.sh:

    $ oc status
    In project imagetest6 on server https://192.168.122.82:8443

    dc/myphp deploys 172.30.30.30:5000/imagetest6-dev/myphp:latest (manual)
      deployment #1 running for 5 minutes - 1 pod

    1 warning identified, use 'oc status -v' to see details.

    $ oc get pods
    NAME             READY     STATUS             RESTARTS   AGE
    myphp-1-4si4s    0/1       ImagePullBackOff   0          5m
    myphp-1-deploy   1/1       Running            0          5m

Docker registry log shows:

    # as system:admin
    $ oc logs dc/docker-registry -n default
    time="2016-11-29T11:34:32.511012884Z" level=debug msg="authorizing request" go.version=go1.6.3 http.request.host="172.30.30.30:5000" http.request.id=086437b9-c257-4969-9dcd-b8b13d51dffc http.request.method=GET http.request.remoteaddr="192.168.121.236:56154" http.request.uri="/v2/imagetest6-dev/myphp/manifests/latest"
    http.request.useragent="docker/1.10.3 go/go1.6.3 kernel/4.8.6-201.fc24.x86_64 os/linux arch/amd64" instance.id=cfdb58fa-9f8e-46f4-a1bf-09de921afb14 vars.name="imagetest6-dev/myphp" vars.reference=latest
    time="2016-11-29T11:34:32.511100227Z" level=debug msg="Origin auth: checking for access to repository:imagetest6-dev/myphp:pull" go.version=go1.6.3 http.request.host="172.30.30.30:5000" http.request.id=086437b9-c257-4969-9dcd-b8b13d51dffc http.request.method=GET http.request.remoteaddr="192.168.121.236:56154" http.request.uri="/v2/imagetest6-dev/myphp/manifests/latest" http.request.useragent="docker/1.10.3 go/go1.6.3 kernel/4.8.6-201.fc24.x86_64 os/linux arch/amd64" instance.id=cfdb58fa-9f8e-46f4-a1bf-09de921afb14 vars.name="imagetest6-dev/myphp" vars.reference=latest
    time="2016-11-29T11:34:32.512974203Z" level=error msg="OpenShift access denied: User \"system:serviceaccount:imagetest6:default\" cannot get imagestreams/layers in project \"imagetest6-dev\"" go.version=go1.6.3 http.request.host="172.30.30.30:5000" http.request.id=086437b9-c257-4969-9dcd-b8b13d51dffc http.request.method=GET http.request.remoteaddr="192.168.121.236:56154" http.request.uri="/v2/imagetest6-dev/myphp/manifests/latest" http.request.useragent="docker/1.10.3 go/go1.6.3 kernel/4.8.6-201.fc24.x86_64 os/linux arch/amd64" instance.id=cfdb58fa-9f8e-46f4-a1bf-09de921afb14 vars.name="imagetest6-dev/myphp" vars.reference=latest
    time="2016-11-29T11:34:32.51306545Z" level=error msg="error authorizing context: access denied" go.version=go1.6.3 http.request.host="172.30.30.30:5000" http.request.id=086437b9-c257-4969-9dcd-b8b13d51dffc http.request.method=GET http.request.remoteaddr="192.168.121.236:56154" http.request.uri="/v2/imagetest6-dev/myphp/manifests/latest" http.request.useragent="docker/1.10.3 go/go1.6.3 kernel/4.8.6-201.fc24.x86_64 os/linux arch/amd64" instance.id=cfdb58fa-9f8e-46f4-a1bf-09de921afb14 vars.name="imagetest6-dev/myphp" vars.reference=latest
    192.168.121.236 - - [29/Nov/2016:11:34:32 +0000] "GET /v2/imagetest6-dev/myphp/manifests/latest HTTP/1.1" 401 152 "" "docker/1.10.3 go/go1.6.3 kernel/4.8.6-201.fc24.x86_64 os/linux arch/amd64"

So the access is denied as expected.

I'll try the quick installation method and see if there's any difference.

For the sake of completeness, here's a list of subjects authorized to pull from imagetest6-dev namespace:

    $ oc policy who-can get imagestreams/layers -n imagetest6-dev
    Namespace: imagetest6-dev
    Verb:      get
    Resource:  imagestreams/layers

    Users:  system:admin
            system:serviceaccount:imagetest6-dev:builder
            system:serviceaccount:openshift-infra:namespace-controller
            ton

    Groups: system:cluster-admins
            system:cluster-readers
            system:masters
            system:serviceaccounts:imagetest6-dev


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