Image caching failed caused by missing pull secret from deleted namespace

[aDisplayName]

kube-image-keeper: v1.10.0

Here is our setup:

1. Deploy kube-image-keeper with latest v1.10.0
2. Deploy a deployment using an image from a private gcr registry: gcr.io/myproject/test-image:0.0.1, while providing image pull secret "gcr-myproject-pullsecret" in namespace "test-1"
3. After the image gcr-io-myproject-test-image-0.0.1 is fully cached, delete the deployment, and delete the namespace "test-1"
4. Deploy a deployment using image: gcr.io/myproject/test-image:0.0.2, using the same image pull secret content in namespace "test-2".
5. The pod will be failed to be deployed, because the Repository.kuik.enx.io object is still referencing to the non-existing "test-1/gcr-myproject-pullsecret` pull secret when caching the new image tag for the same repository.

Our clusters are not hosted on the cloud so we don't know if the recent PR #428 gonna help us.
Question:
Is there a way to specify / inject the global pull secret for the entire cluster for repository using a certain prefixes? We don't mind to inject to kuik deployment if it is allowed.

[paullaffitte]

Hello,

#428 will not help you on this one. And indeed its a bug, I think it will not be to hard to fix, I will try to work on it during this week.

Concerning your question, there is currently no way to do what you ask. You still can use pull secrets attached to a service account and it will be used for pods using this service account, but I understand that it doesn't exactly achieve what you try to do. #385 asked for a similar feature, and while adding an option of a global ImagePullSecret is not something we intend to do, I find the idea of injecting pull secrets for repositories with a specific prefix interesting. But I'm still not sure if it is in the scope of kuik. Maybe a kyverno policy would be enough?

For instance something like this (generated with ChatGPT):

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: add-pull-secret-to-cachedimage
spec:
  rules:
    - name: add-pull-secret
      match:
        resources:
          kinds:
            - CachedImage
      preconditions:
        all:
          - key: "{{ request.object.metadata.labels['kuik.enix.io/repository'] }}"
            operator: In
            value: ["registry.k8s.io-kube-state-metrics-kube-state-metrics"]
      mutate:
        patchStrategicMerge:
          spec:
            imagePullSecrets:
              - name: my-pull-secret # Replace with the desired pull secret name

[paullaffitte]

Hello, I cannot reproduce, or at least not in the way I thought.

Is your issue about the pull secret not being found and thus the program crashes or something nasty like this? Or is it about the pull of the image not being authenticated because the secret is missing?

If you delete a secret the 2nd option is totally expected and there is nothing we can do about it, no secret => no authentication => no pull of the image. Otherwise (1st option) it is a bug but I currently can't reproduce it, attaching related logs here could be helpful.

[aDisplayName]

Hi @paullaffitte , I would believe the 2nd scenario is what happening here.

This is actual a failure scenario, that current mechanism does not cover:
Repository.kuik.enx.io is a cluster-scoped object, but it is referring to a namespace-scoped pull secret.

To the cluster admin, the kuik is supposed to be transparent, so that the admin will not be aware the fact that once the repository from the private registry has been used before, the pull secret in original namespace cannot be removed. Otherwise, just like you said, even the same pull secret has been provided in a different namespace, the kuik operator will not be able to pull a different version of image from the same private registry because the Repository.kuik.enx.io is still trying to looking for the pull secret from the now-deleted namespace, not the from new namespace the same or different pull secret is being stored.

As for my suggestion:

Is there a way to specify / inject the global pull secret for the entire cluster for repository using a certain prefixes? We don't mind to inject to kuik deployment if it is allowed.

Instead the using the pull secret from the namespace where the repository.kuik.enix.io is first time created, the pull secret will be coming from a namespace not going to deleted unexpectedly, thus, solving the problem posed by the failure scenario.