[Scan][Auth] It doesn't block scanning when using incorrect credential

[williamshen9999]

Steps:

• The steps are similar to https://github.com/neuvector/security-ui-exts/discussions/319
• The main difference is, this time, I use wrong user/pw pair (ex: username is nvlab, and pw is "xxxooo1234" which is wrong pw)
• And the created registry is associated with that cert "wrong-pw"

root@sbomscanner-ui-1028:~# k get registry use-wrong-pw  -o yaml
apiVersion: sbomscanner.kubewarden.io/v1alpha1
kind: Registry
metadata:
  creationTimestamp: "2025-10-30T16:38:46Z"
  generation: 1
  name: use-wrong-pw
  namespace: default
  resourceVersion: "722280"
  uid: 87b40c2e-a52c-4ee6-a048-866012cd0874
spec:
  authSecret: wrong-pw
  catalogType: OCIDistribution
  repositories:
  - nvpublic/controller
  uri: docker.io

• Start scan
• It does NOT show any error message and it will keep going the scan process...

root@sbomscanner-ui-1028:~# k get scanjob use-wrong-pwlkdqh -o yaml
apiVersion: sbomscanner.kubewarden.io/v1alpha1
kind: ScanJob
metadata:
  annotations:
    sbomscanner.kubewarden.io/creation-timestamp: "2025-10-30T16:39:09.693160766Z"
    sbomscanner.kubewarden.io/registry: '{"kind":"Registry","apiVersion":"sbomscanner.kubewarden.io/v1alpha1","metadata":{"name":"use-wrong-pw","namespace":"default","uid":"87b40c2e-a52c-4ee6-a048-866012cd0874","resourceVersion":"722280","generation":1,"creationTimestamp":"2025-10-30T16:38:46Z"},"spec":{"uri":"docker.io","catalogType":"OCIDistribution","repositories":["nvpublic/controller"],"authSecret":"wrong-pw"},"status":{}}'
  creationTimestamp: "2025-10-30T16:39:09Z"
  generateName: use-wrong-pw
  generation: 1
  name: use-wrong-pwlkdqh
  namespace: default
  ownerReferences:
  - apiVersion: sbomscanner.kubewarden.io/v1alpha1
    blockOwnerDeletion: true
    controller: true
    kind: Registry
    name: use-wrong-pw
    uid: 87b40c2e-a52c-4ee6-a048-866012cd0874
  resourceVersion: "726456"
  uid: 18346f5c-bb76-4f40-a5a9-cb28fc5c3afc
spec:
  registry: use-wrong-pw
status:
  completionTime: "2025-10-30T16:58:21Z"
  conditions:
  - lastTransitionTime: "2025-10-30T16:39:09Z"
    message: ScanJob completed successfully
    observedGeneration: 1
    reason: Complete
    status: "False"
    type: Scheduled
  - lastTransitionTime: "2025-10-30T16:44:24Z"
    message: ScanJob completed successfully
    observedGeneration: 1
    reason: Complete
    status: "False"
    type: InProgress
  - lastTransitionTime: "2025-10-30T16:44:24Z"
    message: All images scanned successfully
    observedGeneration: 1
    reason: AllImagesScanned
    status: "True"
    type: Complete
  - lastTransitionTime: "2025-10-30T16:39:09Z"
    message: ScanJob completed successfully
    observedGeneration: 1
    reason: Complete
    status: "False"
    type: Failed
  imagesCount: 1
  scannedImagesCount: 1
  startTime: "2025-10-30T16:39:10Z"

Expected behavior:
It should show error message and block the scanning when using incorrect cert.

[flavio]

The registry you're using is a public one. All the registry libraries use authentication only when it's actually needed. In this case, your wrong credentials are never used.

You should repeat the test using a registry that has authentication turned on.

Also, the title of this discussion is "It doesn't block scanning when using incorrect cert" but it's wrong. This is about the credentials (username/password) used to authenticate. TLS certificates are nowhere involved.

[williamshen9999]

Hi @flavio ,
I've changed the title, thanks.
Btw, I'll add more results for this discussions, thanks.

[williamshen9999]

Hi @xingzhang-suse ,

I think we can NOT directly use the Registry Secret created by Storage/Secrets page for testing scan. You could refer to my steps.

After creating Registry Secret created by Storage/Secrets page, it will show in backend like:
root@sbomscanner-ui-1106-rke2:~# k get secret correct-credential-dockerio -o yaml
apiVersion: v1 data: .dockerconfigjson: ${token}

If we decode that ${token} and we will find its format is like:
root@sbomscanner-ui-1106-rke2:~# echo ${token} | base64 -d
{"auths":{"index.docker.io/v1/":{"username":"${user}","password":"${pw}"}}}

However, according to https://github.com/kubewarden/sbomscanner/blob/main/docs/user-guide/private-registries.md ,
The ${token}'s format should be like below. ( and ${auth_value} is the value of "echo ${user}:${pw} | base64 -w 0":
{ "auths": { "https://index.docker.io/v1/": { "auth": "${auth_value}" } } }

So, if I use the format of registry secret created by Storage/Secrets page and do the scan testing below.

• Public repo with correct credential: Finished
• Public repo with incorrect credential: Finished
• Private repo with correct credential: Failed (Error: authentication required...)
• Private repo with incorrect credential: Failed (Error: authentication required...)

I can say that the above result doesn't recognize the secret so it's like scanning without secret...

And, if I manually create the format of registry secret (followed by the backend's doc above) and do the scan testing below.

• Public repo with correct credential: Finished
• Public repo with incorrect credential: Failed (Error: 401 unauthorized...)
• Private repo with correct credential: Finished
• Private repo with incorrect credential: Failed (Error: 401 unauthorized...)

The above result makes sense. (It can recognize the secret and scan with the secret)

Could you kindly check and let me know? Thanks.

Hi @flavio,
Please also help to correct if I'm wrong. Thanks.

[flavio]

The problem is with the contents of the secret created by the UI index.docker.io/v1/ instead of https://index.docker.io/v1/.

For some reason which baffles me, Docker HUB wants to be addressed with the https:// prefix. Other registries do not require that AFAIK

[williamshen9999]

Hi @xingzhang-suse ,
Could you help to check if which rough version of UI will fix this bug? Thanks...
cc: @selvamt94

[williamshen9999]

Hi @xingzhang-suse ,
Could you check which version of UI will fix this bug? Thx.
cc: @jchan-suse @selvamt94

[xingzhang-suse]

Hi @williamshen9999 ,

The workflow in the backend is to user the secret name from registry configuration to get the secret from secret's k8s resource.
SBOMScanner UI extension only pass the secret name to the backend. So there is nothing can be done for this issue on the UI extension. Please file a github issue to the rancher/dashboard repo.

(Please refer the documentation below, it show how the secret set to the CRD)
https://github.com/kubewarden/sbomscanner/blob/main/docs/user-guide/private-registries.md#create-the-secret
https://github.com/kubewarden/sbomscanner/blob/main/docs/user-guide/private-registries.md#create-the-registry

[williamshen9999]

I found that this problem can be solved by using "Custom" secret in Rancher UI.

[williamshen9999]

Hi @xingzhang-suse @flavio

Let me provide a quick summary.

For docker hub, In Rancher UI,

when trying to use "DockerHub" secret -> then the secret will NOT take effect for Sbomscanner (coz the Registry Domain Name will be set as "index.docker.io/v1/" ; it lacks prefix "https://" )

however, you can use "Custom" secret (and manually specify "https://index.docker.io/v1/") -> then the secret will take effect for Sbomscanner

In the future, if someone met this problem by using "DockerHub" secret in Rancher UI, then he/she can be suggested to use "Custom" secret.
Then we don't need to ask Rancher to modify (since some products might already be under using "DockerHub" secret in Rancher UI; it might be risky if we ask Rancher to modify the value).

Let me know if it's okay? Thanks. :)

[flavio]

I think @xingzhang-suse has a point in reaching out to the Rancher team. That's because the Rancher UI is creating a secret that is wrong for interacting with the Docker Hub.

A user might rely on that secret to pull a container image from a private repository on Docker Hub.

Now, if you do a docker login against Docker Hub, the resulting .docker/config.json file will show something like:

        "auths": {
                "dp.apps.rancher.io": {},
                "ghcr.io": {},
                "https://index.docker.io/v1/": {}
         }

Notice how Docker Hub is the only registry that has the https:// prefix. If you strip that even docker daemon will not be able to pull from there.

Sure, using the custom secret can be a workaround, but there's a problem here.

[williamshen9999]

Hi @flavio ,
Sure, as we discussed in the daily, let's use custom secret for a workaround; meanwhile, I'll file a bug to rancher/dashboard repo and track. Thanks.