-
Notifications
You must be signed in to change notification settings - Fork 1.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
"no valid providers in chain" in Jenkins #1270
Comments
Somebody can help me? It is for my final degree project :( |
I am also running into this issue with a gitlab-ci build running on kubernetes. My gitlab-ci.yml job looks like:
|
I was able to build with this base image gcr.io/kaniko-project/executor@sha256:f652f28537fa76e8f4f9393de13a064f0206003c451ce2ad6e4359fd5a21acbc from a month ago. Not really a fix, but a workaround. |
I'm also seeing this from within a GKE cluster. We've been using kaniko in the cluster happily. This morning we enabled the workload identity feature and metadata server and kaniko now hangs as described. |
In my case, this was caused by a network policy preventing access to the Google Metadata Server ( Even though the network policy allowed egress on port 80, this didn't work. Kaniko should IMHO timeout after some (reasonably short) period when trying to get credentials. |
duplicate of #1287 |
This is bonkers - why should my Kaniko build need to be able to talk to the Google Metadata Server when it's building from a Dockerfile in a directory, and outputting to a tar file? |
I've tried building the container from HEAD and I'm still seeing some issues unfortunately. I've done a bunch of digging and I think our issue is actually just the "infinite loop" behaviour of the GCR credential package in https://github.com/vdemeester/k8s-pkg-credentialprovider as we are a) running on GCE but b) have blocked access to the metadata server as we are running untrusted workloads. I think this assumption then doesn't work for our setup https://github.com/vdemeester/k8s-pkg-credentialprovider/blob/8edca87436b8a9a0924e8c6168177cd1854bd186/gcp/metadata.go#L215. Do you think it would be reasonable to either a) not infinitely loop or b) be able to control which providers Kaniko attempts to register (rather than just relying on init functions)? This is unrelated to the Thanks for looking into this! |
Thanks @andy-paine for confirming this is related to the GCP metadata server. Thanks |
Thanks, i am looking to code where |
Im trying to use Kaniko in my Jenkinsfile:
And always I get the following error
And my pipeline does not stop never.
Somebody knows what is the problem?
Thanks!
The text was updated successfully, but these errors were encountered: