The Multiarch Tuning Operator does not support wildcard entries in the global pull secret when attempting to inspect images. While other components like kubelet and CRI-O handle wildcard domains correctly (e.g., *.docker.bin-i.example.ch), the operator fails with an unauthorized error. Logs indicate that the operator expects an exact match of the registry hostname and does not fallback to wildcard matches. This results in failed image inspections for registries that rely on dynamic or multi-tenant structures, limiting flexibility.

    Always, when using wildcard entries in the global pull secret for registries accessed by the multiarch-tuning-operator.

    1.Add a wildcard entry (e.g., *.docker.bin-i.example.com) to the global pull secret.


2. Ensure kubelet and CRI-O can pull images like dockerio.docker.bin-i.example.ch/jmalloc/echo-server:v0.3.7 successfully.


3. Deploy or trigger the multiarch-tuning-operator to inspect an image hosted on the same registry.     
    

    The multiarch-tuning-operator fails with an unauthorized error. Logs confirm it attempts to match the full registry hostname literally and does not utilize the wildcard from the global pull secret.

    The operator should behave like kubelet and CRI-O by supporting wildcard entries in the pull secret and successfully authenticate and inspect the image.

Sample wildcard entry from global pull secret:
jsonCopyEdit{
  "auths": {
    "*.docker.bin-i.example.ch": {
      "auth": "b2N..."
    }
  }
}

Observed error from operator logs:
makefileCopyEditunauthorized: The client does not have permission for manifest...

This is a critical limitation in environments using dynamic or multi-tenant registries and should be aligned with behavior seen in kubelet and CRI-O.