https://rancher.com/ logo
Join Slack
Powered by
This message was deleted.
# rancher-desktop
a
This message was deleted.
w
and the on in your image registry was built with the exact same dependencies? No latests or EXECs that could be adding different results to the union?
a
nothing, works good on my colleagues laptop. I faced this issue a month back as well but in that case I removed my existing docker images as it used to take existing layer after that it got resolved.
w
well if teh hash is the exact same it would take the existing layer?
a
but currently I do not have any existing layer I deleted all the previous one and reset rancher as well to be sure.
starting a fresh docker build
w
and docker manifest for the image you build local and the one you pull from your registry are equal
a
ditto, I just use it in FROM layer FROM BaseImagePath
w
just seems odd to me that a manifest result from one image that trivvy or some tool is saying contains a flaw is the same as a manifest from another image where the same tool says there is no flaw
a
indeed as per me there is still some cache stored which is causing this
w
thats not how docker works though
unless you are doing something runtime that is not in the image
a
ok but it does fetches the existing layers and maybe somewhere residue is left, just a random guess cause can’t think of anything else
w
nope it would only fetch layers with a hash match
a
i’m clueless then, if not rancher then what
w
rancher just orchestrates docker or containerd so this is out of their scope. this is something in your dockerfile most likely. without the dockerfile its hard to know what could be introducing the ambiguity you are talking about
a
one liner Dockerfile- FROM base-images/alpine_node-14:latest
w
well latest is an ambiguous statement
a
well if I use the same latest tag to pull directly from the dockerhub, no vulnerability then
w
your registry image may have a different version than the one you are pulling at this moment, but the manifest would show a different hash
a
docker pull *
what if I tell you that I use a specific version instead of latest then also I get the same number of vulnerabilities.
w
and that image in your registry that has zero vulns is using the same verison (hash compare)
a
give me sometime to compare, I guess hash won’t be same when I’m building it in my local.
w
and looks like you are using images by https://github.com/mhart/alpine-node as opposed to the nodejs generated options https://github.com/nodejs/docker-node
a
ignore that these are from my organisations registry
w
well trying to figure out why you are getting ambiguous results. images are just collections of zip files so vuln scanners tend to provide the same results for the same image
and if your internal base has a mess of vulns well I would work with that upstream to rebuild
a
it is vulnerability free, give me a moment. will get back to you with results.
sorry to kill your time, it was an honest mistake if I use the absolute image name it works earlier it was taking vulnerability from some other registry when I was partially using the image name in my Dockerfile
👍 1
when I used to login to my companys docker registry it used to fetch the complete name and fetch image from there but now the behaviour isn’t the same. I thought just like last time maybe some rancher cleanup would help.
thanks anyways.
w
yeah thats where manifest inspect is your friend. the hashes shouldn’t lie
a
Indeed.
hey actually the issue was not that. I created dockerfile in a new folder then it started fetching from correct registry. In my older folder there were already 10dockerfiles and whenever I create my build from there it fetches from docker.io registry by default.
w
you can definitely use your .docker/config to override the default registry, but definitely recommend fully qualifying your image URL and not just allowing dockerd to inject it in. Helps to avoid these type of issues.
9 Views
Open in Slack
PreviousNext
Powered by