Pulling from private registries

76 views
Skip to first unread message

Sean McCann

unread,
Aug 4, 2021, 6:49:01 AM8/4/21
to Knative Users
Hey all,

I ran into a problem recently on OCP where my KSVC fails with:
Revision failed with message: Unable to fetch image  failed to resolve image to digest: GET Authentication is required.

I'm using a private artifactory registry, but up until now this was not a problem because my KSVC has a serviceAccountName attached to it which has the correct pull secret. I can use this service account in other pods and the images pull successfully.

I only started seeing this problem once I tried to deploy into a new namespace separate from my non Knative parts of the application. The new namespace also has the same image pull secret and the same service account, so i'm confused as to why it's failing to resolve image to digest. The service account works for other pods, just not resolving the image.

https://github.com/knative/serving/issues/6895 I was reading this issue and skipping tag resolution does solve the problem, but the nature of my application it's hard to specify a list of registries to ignore. Supplying the digest directly also is not ideal as it does not fit well into our pipeline.

Does anyone have any ideas as to what difference between the namespaces could be causing this problem? It's really strange to me that using the same secret and service account the deployment only works in one of the namespaces, so there must be something linking my KSVC to the original namespace, I just can't figure out what it is.

Any advice or possible areas to investigate would be so helpful if anyone has any tips! Thanks.


Salaboy Mauricio Salatino

unread,
Aug 4, 2021, 7:26:11 AM8/4/21
to Sean McCann, Knative Users
Is this not related with the fact that secrets work only on the namespace that’s they are defined? 

Sent from my iPhone

On 4 Aug 2021, at 12:49, Sean McCann <inboundem...@gmail.com> wrote:

Hey all,
--
You received this message because you are subscribed to the Google Groups "Knative Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to knative-user...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/knative-users/61e3fd4b-e304-4d27-8e16-2a989ee7fd90n%40googlegroups.com.

Sean McCann

unread,
Aug 4, 2021, 3:47:21 PM8/4/21
to Knative Users
So it turns out the mechanism that copies over my secret actually changed the secret type to Opaque which was causing the problem. The knative service was failing for a legitimate reason. When I tested the secret on a different pod it appeared to work because the image I references was actually already present on the cluster so it never had to hit the private registry at all which made me think the problem was specifically with my Knative service. 

Oops!

Thank you for your reply though, you were right that the secret only worked in the first namespace, the problem was when it was copied to the second.

Salaboy Mauricio Salatino

unread,
Aug 5, 2021, 5:26:49 AM8/5/21
to Sean McCann, Knative Users
Sean, I am happy to hear that it is working now! Cheers 

Sent from my iPhone

On 4 Aug 2021, at 21:47, Sean McCann <inboundem...@gmail.com> wrote:

So it turns out the mechanism that copies over my secret actually changed the secret type to Opaque which was causing the problem. The knative service was failing for a legitimate reason. When I tested the secret on a different pod it appeared to work because the image I references was actually already present on the cluster so it never had to hit the private registry at all which made me think the problem was specifically with my Knative service. 
Reply all
Reply to author
Forward
0 new messages