Skip to content
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

Add ability to use public GCR repos without being authenticated #1140

Merged
merged 7 commits into from
Mar 24, 2020

Conversation

samos123
Copy link
Contributor

Apply lazy configuration of docker credential helper for GCR at run-time only when GCR is used as the destination.

Fixes #1122

Submitter Checklist

These are the criteria that every PR should meet, please check them off as you
review them:

  • Includes unit tests
  • Adds integration tests if needed.

See the contribution guide for more details.

Reviewer Notes

  • The code flow looks good.
  • Unit tests and or integration tests added.

Release Notes

Add ability to use public GCR images without being authenticated to GCR

Previously there was a need to import public GCR images into the local
docker registry and replace the base images to use the local docker
registry. This is no longer needed since Kaniko now works with public
GCR images also for unauthenticated users.
@googlebot googlebot added the cla: yes CLA signed by all commit authors label Mar 16, 2020
@samos123 samos123 changed the title Fix 1122 public gcr Add ability to use public GCR repos without being authenticated Mar 16, 2020
@samos123 samos123 requested a review from tejal29 March 16, 2020 21:56
@samos123 samos123 requested a review from cvgw March 17, 2020 00:58
samos123 and others added 2 commits March 17, 2020 09:09
Kaniko by default used to configure the GCR credential helper however
this caused Kaniko to fail when trying to use a base image from a public
GCR image. This patch makes it possible to use public GCR images as base
image when using docker even when you're not authenticated to GCR.

Co-authored-by: Nate Williams <nate.williams@files.com>
@googlebot
Copy link

All (the pull request submitter and all commit authors) CLAs are signed, but one or more commits were authored or co-authored by someone other than the pull request submitter.

We need to confirm that all authors are ok with their commits being contributed to this project. Please have them confirm that by leaving a comment that contains only @googlebot I consent. in this pull request.

Note to project maintainer: There may be cases where the author cannot leave a comment, or the comment is not properly detected as consent. In those cases, you can manually confirm consent of the commit author(s), and set the cla label to yes (if enabled on your project).

ℹ️ Googlers: Go here for more info.

@googlebot googlebot added cla: no CLA not signed by all commit authors and removed cla: yes CLA signed by all commit authors labels Mar 17, 2020
@samos123
Copy link
Contributor Author

samos123 commented Mar 17, 2020

@filesnate I added you as co-author since you made the original PR and I just improved on it. If that's fine with you, please add a comment here with following message: "@googlebot I consent."

Also thank you for the thorough reviews and testing to make sure it works for your use case as well.

@filesnate
Copy link
Contributor

@googlebot I consent.

@googlebot
Copy link

CLAs look good, thanks!

ℹ️ Googlers: Go here for more info.

@googlebot googlebot added cla: yes CLA signed by all commit authors and removed cla: no CLA not signed by all commit authors labels Mar 17, 2020
@filesnate
Copy link
Contributor

@filesnate I added you as co-author since you made the original PR and I just improved on it. If that's fine with you, please add a comment here with following message: "@googlebot I consent."

Also thank you for the thorough reviews and testing to make sure it works for your use case as well.

Thank YOU for doing the heavy lifting in the go code that I way less familiar with!

// Historically kaniko was pre-configured by default with gcr credential helper,
// in here we keep the backwards compatibility by enabling the GCR helper only
// when gcr.io is in one of the destinations.
if strings.Contains(destRef.RegistryStr(), "gcr.io") {
Copy link
Member

@tejal29 tejal29 Mar 17, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you please test to push to a public GCR repo one needs to be authenticated? My gut is mostly yes in which case this is good. If not, then we might need to add this is documentation.

It would be great if you can add tests for this function.

  1. You can declare 2 variables
// for testing
var (
execute = execCommad
checkRemotePushPermissions = remote.CheckPushPermission
stat = os.Stat
)

In your tests, you could create mock for these and make sure,

  1. when mockOsStat return os.ErrNotExist, execute is called
  2. when mockOsStat return nil and some random fileinfo, execute is not called.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I added the testing. I noticed we were already using afero in push.go and push_test.go so there wasn't a need to mock os.Stat. Thank you so much for detailed recommendations on how to test, really helpful.

There is no way to make a GCR repo pushable by the public. You can only push if you're explicitly given permission to push to a GCR repo. For reference: https://cloud.google.com/container-registry/docs/access-control or did you mean something else?

pkg/executor/push.go Outdated Show resolved Hide resolved
Copy link
Member

@tejal29 tejal29 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Add tests and 1 nit.

Copy link
Member

@tejal29 tejal29 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You will also need to remove the DOCKER_CREDENTIAL_GCR_CONFIG from all the Dockerfiles.

@samos123
Copy link
Contributor Author

DOCKER_CREDENTIAL_GCR_CONFIG should be left in the Dockerfiles since we're not setting it in push.go. It will only be used when docker-credential-gcr configure-docker is run through push.go. Setting the environment variable in push.go would be less clean imo.

@tejal29
Copy link
Member

tejal29 commented Mar 24, 2020

I just realized this will remove file/kaniko/.docker/config.json in user workspace if it previously existed as a side effect. - ofc a rare case.
It would be ideal if for testing,

  1. we could override the variable,
  2. create a config file using ioutil.TempFile and then
  3. delete it in defer.

@samos123
Copy link
Contributor Author

/kaniko/.docker/config.json won't get deleted since afero creates membased temporary mock FS during unit test. In addition execCommand is stubbed out with a fake exec command during unit tests.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
cla: yes CLA signed by all commit authors
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Kaniko can't pull public images from gcr.io
4 participants