openshift / origin

Conformance test suite for OpenShift
http://www.openshift.org
Apache License 2.0
8.49k stars 4.7k forks source link

Cannot get manifest for ImageStream referencing external image #18831

Closed nacef-labidi closed 6 years ago

nacef-labidi commented 6 years ago

After adding an ImageStream referencing a docker.io image, I cannot get manifest through registry REST API

Version
oc v3.7.1+ab0f056
kubernetes v1.7.6+a08f5eeb62
features: Basic-Auth GSSAPI Kerberos SPNEGO

Server https://openshift.op.acp.adeo.com:443
openshift v3.7.1+ab0f056
kubernetes v1.7.6+a08f5eeb62
Steps To Reproduce
  1. Create ImageStream in project referencing a docker.io image

    apiVersion: image.openshift.io/v1
    kind: ImageStream
    metadata:
    name: centos
    namespace: mytestproject
    spec:
    dockerImageRepository: docker.io/library/centos
    lookupPolicy:
    local: false
  2. curl -kv -X GET -H "Authorization: Bearer xxxxxxxxxxx" http://myregistry.mydomain.com/v2/mytestproject/centos/manifests/latest

Current Result
<---- HTTP RESPONSE:
HTTP/1.1 404 Not Found
Content-Length: 142
Content-Type: application/json; charset=utf-8
Date: Mon, 05 Mar 2018 13:08:41 GMT
Docker-Distribution-Api-Version: registry/2.0
Set-Cookie: 41a9fbc321c0026414bbe3c2eb00f854=75bc7fa4b2bee1973867b9b8840a4160; path=/; HttpOnly; Secure
X-Registry-Supports-Signatures: 1

{"errors":[{"code":"MANIFEST_UNKNOWN","message":"manifest unknown","detail":{"Op":"Get","URL":"https://registry-1.docker.io/v2/","Err":{}}}]}
Expected Result

Obtain manifest of ImageStream

jwforres commented 6 years ago

@openshift/sig-developer-experience

bparees commented 6 years ago

There should be no reason to expect the manifest to be retrievable via the registry. Creating/importing an imagestream simply imports some metadata about the image into openshift so that resources such as pods/deployments can reference it. It doesn't touch the internal registry.

What lead you to expect this behavior and why do you need it?

nacef-labidi commented 6 years ago

This works for images pushed directly into the registry, so I expect that it works for ImageStreams referencing external images. And from what I see in the returned error message that it tries to contact the source registry of the image but fails for some reason. I need that behavior to be consistent for all the images as I am performing a vulnerability scan of all images in our registry and the scan fails when an ImageStream references an external image, works perfectly for the rest.

bparees commented 6 years ago

This works for images pushed directly into the registry, so I expect that it works for ImageStreams referencing external images.

If you push an image to the registry, the registry has the data and can return it to you. If you create an imagestream, all you've done is make a symlink in openshift, the registry itself has no content related to the image, except some metadata.

And from what I see in the returned error message that it tries to contact the source registry of the image but fails for some reason.

@dmage might be able to shed some light on why the error message is the way it is(referencing the external repo for the image) ({"errors":[{"code":"MANIFEST_UNKNOWN","message":"manifest unknown","detail":{"Op":"Get","URL":"https://registry-1.docker.io/v2/","Err":{}}}]}) but effectively you've asked the registry for content is does not have/will not have. I don't believe we have any expectation that the registry would attempt to proxy that request on to the external registry for you in this scenario.

I need that behavior to be consistent for all the images as I am performing a vulnerability scan of all images in our registry and the scan fails when an ImageStream references an external image, works perfectly for the rest.

I think you should be looking at the dockerImageReference status of the imagestreamtag you're trying to scan. If it doesn't point to the openshift registry, you shouldn't be asking the openshift registry for the manifest for that image.

e.g.:

    - created: 2018-03-09T16:35:31Z
      dockerImageReference: 172.30.37.4:5000/test/origin-ruby-sample@sha256:520695a3b54f9c4758553fa98f330811ef8dcb45b9f1705b3cd54007e4799bf7
      generation: 1
      image: sha256:520695a3b54f9c4758553fa98f330811ef8dcb45b9f1705b3cd54007e4799bf7
    tag: latest

vs

    - created: 2018-03-09T16:33:28Z
      dockerImageReference: centos/ruby-22-centos7@sha256:b2637a0ae69beb30111425fd381d5ff01acb0d71e9d61b491c3eaba54e5428ef
      generation: 2
      image: sha256:b2637a0ae69beb30111425fd381d5ff01acb0d71e9d61b491c3eaba54e5428ef
    tag: latest
dmage commented 6 years ago

@nacef-labidi can you provide us with logs from the registry pod? It should work.

openshift-bot commented 6 years ago

Issues go stale after 90d of inactivity.

Mark the issue as fresh by commenting /remove-lifecycle stale. Stale issues rot after an additional 30d of inactivity and eventually close. Exclude this issue from closing by commenting /lifecycle frozen.

If this issue is safe to close now please do so with /close.

/lifecycle stale

openshift-bot commented 6 years ago

Stale issues rot after 30d of inactivity.

Mark the issue as fresh by commenting /remove-lifecycle rotten. Rotten issues close after an additional 30d of inactivity. Exclude this issue from closing by commenting /lifecycle frozen.

If this issue is safe to close now please do so with /close.

/lifecycle rotten /remove-lifecycle stale

openshift-bot commented 6 years ago

Rotten issues close after 30d of inactivity.

Reopen the issue by commenting /reopen. Mark the issue as fresh by commenting /remove-lifecycle rotten. Exclude this issue from closing again by commenting /lifecycle frozen.

/close