kubernetes scanner not showing results

Dan_Woolf

Just an update: We are still looking into the issue. We are currently having trouble recreating the same API output as yours. In our tests, the imageId returned for the container status contains a different digest. We are digging further into the Rancher documentation, specifically around their Kubernetes configuration.

If you have any tips on some specific Rancher/Kubernetes configurations we should look for, please let us know.

Thanks,
Dan

cronventis

@Dan_Woolf Sorry to say that, but I really dont know how to help you further. I sent you another json (could be identical, or only have small changes) but was created in a different way.. Maybe this is more useful?

atripp

Hi @cronventis, just wanted to let you know that this is complicated and it's not something we cannot quickly debug/diagnose.

Based on our analysis, the data being returned from your Kubernetes API is different than our instance, and the instances we've seen in the field. Our instance's API is returning the configuration digest, but it looks like your instance is returning the manifest digest.

Which one is correct? Why is your instance doing that? Why is ours doing this? It's a mess

Code-wise, it would be a trivial fix in ProGet to make. Basically we just change this...

var data = await new DB.Context(false).ContainerUsage_GetUsageAsync(Feed_Id: this.FeedId, Image_Id: this.Image.ContainerConfigBlob_Digest);

... to this...

var data = await new DB.Context(false).ContainerUsage_GetUsageAsync(Feed_Id: this.FeedId, Image_Id: this.Image.Image_Digest);

... except that would break our instance and the others that return configuration digests.

We're tempted to "munge" the data results (basically just concatenate both database resultsets), but it would be really nice to know (1) which is correct and (2) why one instance does one thing.

Anyways that's our latest thought. Do you have any insight into this? This is just so bizarre.

Well, we'll kepe thinking about it on our end as we have time. Just wanted to give you a sitrep.

Cheers,
Alana

cronventis

@atripp Uh.. Ok.. Yes this sounds like an interesting topic ;)

I can give you one more insight.. This is our first k8s setup, and we have chosen to run our own cluster, locally. So we don't use aws, azure or google... Basically this menas: we could have done anything wrong when setting up the cluster.. Missing something, adding something that does not belong there, and so on...

For me personally, the information in ProGet is currently nothing I HAVE to have, I actually just wonted to test this and see what is possible ;)

In maybe 6-12 months we will probably do a migration to azure k8s, maybe then it will work.. But I think for now, I have wasted enough of your time... Thank you for taking such a detailed look into this issue!

Dan_Woolf

Hi @cronventis,

Thanks for the details. Let us know when you shift over to Azure k8s if that fixes your issue or not. I would love to figure out what configuration made it change that value, but I can definitely understand holding off until you make your final shift.

Thanks,
Dan

cronventis

@Dan_Woolf I may have another Idea.... We are running on containerd ... not on dockerd...
Maybe this makes a difference: https://github.com/kubernetes/kubernetes/issues/95968

atripp

Hi @cronventis ,

Great find - that seems to explain what we're seeing: containerd reports on containers differently than dockerd. So, we'll just search for container images based on configurationblob_digest OR image_digest

This change was trivial, and will be in the next maintenance release (or available as a prerelease upon request) as PG-2081 - scheduled release date is Feb 11.

Cheers,
Alana

cronventis

@atripp Wunderfull... Glad I could help.. Looking forward to test when it arrives :)