kubernetes: imagePullSecrets should log warning if secret does not exist
What happened:
imagePullSecrets can added to a pod manifest to reference a secret containing registry credentials. Currently, if you add the name of a secret that does not exist, there is no warning or error.
What you expected to happen:
I would expect there to be an error and a failed deployment if the secret does not exist/cannot be found in the namespace. If people are pulling public images, they may still wish to authenticate to a registry, for example dockerhub, before pulling the image, in order to utilise their subscription account rate limits. Currently if they use imagePullSecrets and the referenced secret does not exist, they may assume they are authenticating to their account when they are not, and will still be able to pull public images without any warning that authentication is not taking place.
How to reproduce it (as minimally and precisely as possible):
Add imagePullSecrets: myfakesecret to a pod spec, and pull images from docker.io.
About this issue
- Original URL
- State: closed
- Created 3 years ago
- Reactions: 9
- Comments: 61 (35 by maintainers)
Commits related to this issue
- Added warning event when fetching ImagePullSecret fails #104432 — committed to charan1998/kubernetes by charan1998 2 years ago
correct me if not. Pulling private images with nonexists secret, pod will turn to
ErrImagePull. However, pulling public image with nonexists secret, no error will display yet.gotcha, that seems more reasonable, thanks for clarifying
as a note, make sure the warning events are generated at most once in that function, rather than once per missing secret object (if there are multiple missing secrets)
Hi!
It feels that this issue is stalled (although it lacks the label) and the related PRs have been abandoned. I’ll work on it if that’s ok 😊
/assign
Thanks for the offer, but it looks like https://github.com/kubernetes/kubernetes/pull/109492 was open and had an update that was waiting for review (which I didn’t realize)
Feel free to work on this @charan1998 , you can refer to https://github.com/kubernetes/kubernetes/pull/104535 for some advices.
I think @calvin0327 has created a pr above and labeled /lgtm already.
Yes, a warning would be good. I feel an error would have be better, but as has already been mentioned above we are too far along now for this change as it could break some users existing deployments, so a warning makes the most sense now.
I would like to work in this. /assign