Credential helper support in kaniko build

[mchmarny]

[imjasonh]

Kaniko should use k8schain to automatically pick up k8s credentials. It currently only uses authn.DefaultKeychain to authorize pushes (and base image pulls).

/cc @dlorenc @mattmoor

[dlorenc]

is k8schain going to move somewhere permanent?

[mattmoor]

I think we should move it under authn as a subpackage. It'll mean vendoring more into ggcr, but it will also be prunable by consumers of the library (unless they use k8schain).

The main modification I want is to support a no-K8s-client version (just the contextual auth == universal cred helper). Right now it is meant to be linked by a K8s controller that can do super-userish things like grab secrets, and we don't want to require that in all contexts (e.g. kaniko).

[mattmoor]

@dlorenc @ImJasonH https://github.com/google/go-containerregistry/pull/226

[mattmoor]

I think we still need the capacity to compose authn.Keychains, so that k8schain can be a fallback when authn.DefaultKeychain falls back on anonymous. I'll think on this and hopefully get a (separate) PR together.

[mattmoor]

This will be fixed by: https://github.com/GoogleContainerTools/kaniko/pull/243

[jchesterpivotal]

... just ran smack into this one :|

[imjasonh]

@jchesterpivotal I'm confused, I would expect this to be fixed by https://github.com/GoogleContainerTools/kaniko/pull/243 which has been merged and released AFAIK.

What's the error you're seeing?

[mattmoor]

I think kaniko needs to release?

[imjasonh]

https://gcr.io/kaniko-project/executor claims the image was released 2 hours ago, and has many builds since that PR was merged.

/cc @priyawadhwa

[mattmoor]

https://github.com/GoogleContainerTools/kaniko/tree/v0.1.0 ?

[priyawadhwa]

It looks like gcr.io/kaniko-project/executor:latest isn't the same as when I build it locally @ HEAD

We use build triggers to deploy the image, and I think something went wrong there because the commit tagged version of the image gcr.io/kaniko-project/executor:8f71b7fb260cd08f1acd9b7854df9a82a444382c is correct, but gcr.io/kaniko-project/executor:latest, which is built via

docker tag gcr.io/kaniko-project/executor:8f71b7fb260cd08f1acd9b7854df9a82a444382c gcr.io/kaniko-project/executor:latest

is different.

I reran the trigger and they seem to be the same now, so hopefully that should fix this issue. Unfortunately I'm not sure why it happened :(

[jchesterpivotal]

Still seeing this behaviour. I may be looking at a different bug on Kaniko though.

[priyawadhwa]

@jchesterpivotal , could you comment on that issue with more some more information? The error you're seeing and the Dockerfile you're trying to build would be really helpful.