proposal: transmit more information to remote snapshotter

[sctb512]

What is the problem you're trying to solve

We tried to find the best way for the remote snapshotter to get auth, but ultimately think it should get auth when it needs other than stored in memory or other space.

Since k8s 1.8, the node authorizer has been proposed, which has the ability to Get secrets used by pods scheduled on that node. So remote snapshotter can use kubeconfig, which is used by kubelet, to get imagePullSecret when it needs it. When we do this, all we need is pod.Namespace and pod.Spec.imagePullSecret.Name.

Related to issue Change List to Get when sync imagePullSecret from API server

Describe the solution you'd like

So I wonder if the containerd can pass more information to the remote snapshotter? For instance, pod.Namespace and pod.Spec.imagePullSecret.Name.

Additional context

No response

[Jenkins-J]

Is it possible to pass pod.Namespace and pod.Spec.imagePullSecret.Name to the snapshotter using user-defined labels, like in the Remote Snapshotter documentation, for this case?

[sctb512]

Is it possible to pass pod.Namespace and pod.Spec.imagePullSecret.Name to the snapshotter using user-defined labels, like in the Remote Snapshotter documentation, for this case?

Yes, I believe it's simple to implement this feature. I'm wondering if we can add this to containerd to automatically add these labels before calling remote snapshotter interface.

[Jenkins-J]

I've looked into this a little more. I do not think that containerd has access to the name of the image pull secret. As far as I know, it seems that kubelet first uses the image pull secret name to access the credentials, then passes down the credentials (not the image pull secret name) to containerd through the PullImageRequest when calling the CRI API (Please correct me if I'm wrong here). I'm not sure if this changes the approach.

[sctb512]

I've looked into this a little more. I do not think that containerd has access to the name of the image pull secret. As far as I know, it seems that kubelet first uses the image pull secret name to access the credentials, then passes down the credentials (not the image pull secret name) to containerd through the PullImageRequest when calling the CRI API (Please correct me if I'm wrong here). I'm not sure if this changes the approach.

Yes, I have tried to implement this feature but encountered the same problem as you mentioned.

Need more consideration about how the remote snapshotter updates/restores credentials.
In theory, only image related information should be sent to the remote snapshotter. Without a remote snapshotter, containerd will return an error and the kubelet will retry with the new credential if it has expired. However, for remote snapshotter, the container has been started and can not return an error to kubelet this time.