Cannot get manifest for ImageStream referencing external image

[nacef-labidi]

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]

@openshift/sig-developer-experience

[bparees]

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]

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]

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]

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

[openshift-bot]

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]

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]

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