openshift/builder

Push secret not found if pull secret is not present

Closed this issue · 10 comments

adambkaplan commented

If a build config has a push secret, but does not have a pull secret, the push secret config is not found. Builder looks for a config.json file, which is not created by oc create secret docker-registry ...

Steps to reproduce

  1. Create a docker-registry secret: oc create secret docker-registry ${secret} --docker-email=${email} --docker-username=${username} --docker-password=${password} --docker-server=${registry}
  2. Link the secret to the builder service account: oc secret link builder ${secret}
  3. Create a build config that pushes an image to a repo that requires registry auth (ex: Docker Hub) with the above secret, but does not use a pull secret.

Expected result
Push secret is found and used to push image upon successful build.

Actual result
Failure to find the push secret:

ERROR: logging before flag.Parse: I1022 17:49:23.993670       1 sti.go:393] Locating docker auth for image docker.io/adambkaplan/ruby-ex:latest and type PUSH_DOCKERCFG_PATH
ERROR: logging before flag.Parse: I1022 17:49:23.993696       1 sti.go:393] Getting docker auth in paths : [/var/run/secrets/openshift.io/push]
ERROR: logging before flag.Parse: I1022 17:49:23.993705       1 config.go:131] looking for config.json at /var/run/secrets/openshift.io/push/config.json
ERROR: logging before flag.Parse: I1022 17:49:23.993879       1 builder.go:300] No push secret provided

Pushing image docker.io/adambkaplan/ruby-ex:latest ...
Pushing image "docker.io/adambkaplan/ruby-ex:latest" from local storage.
No authentication secret provided for pushing to registry.
Registry "docker.io" is marked as secure in the registries configuration.
Getting image source signatures
Copying blob sha256:1d31b5806ba40b5f67bde96f18a181668348934a44c9253b420d5f04cfb4e37a

 0 B / 198.64 MiB 
 8 B / 198.64 MiB  0s
ERROR: logging before flag.Parse: F1022 17:49:24.411146       1 helpers.go:119] error: build error: Failed to push image: error copying layers and metadata from "containers-storage:[overlay@/var/lib/containers/storage+/var/run/containers/storage:overlay.skip_mount_home=false,overlay.mountopt=nodev,overlay.override_kernel_check=false]docker.io/adambkaplan/ruby-ex:latest" to "docker://adambkaplan/ruby-ex:latest": Error writing blob: Error initiating layer upload to /v2/adambkaplan/ruby-ex/blobs/uploads/ in registry-1.docker.io: errors:
denied: requested access to the resource is denied
unauthorized: authentication required
zoobab commented

Same issue here, when you do an "oc edit bc myproject", you see that the pushSecret is still there:

$ oc edit bc myproject
[...]
spec:
  nodeSelector: null
  output:
    pushSecret:
      name: regcred
    to:
      kind: ImageStreamTag
      name: myproject:latest

Trying to find a way with oc patch to nullify the pushSecret field...

zoobab commented

OK I found a workaround by applying a kubectl patch, where the pushSecret field is empty:

$ cat patch-bc.yaml
---
spec:
  output:
    to:
      kind: ImageStreamTag
      name: myproject:latest
    pushSecret:

$ oc patch bc myproject --patch "$(cat patch-bc.yaml)"
buildconfig "myproject" patched
bparees commented

@adambkaplan this seems bad, is it still broken in this way?

bparees commented

@adambkaplan we concluded this is working correctly, right?

jovemfelix commented

For me I to work I had to set associate the secret with the builder as follows:
oc -n my_namespace secrets link builder my_secret_to_pull_images

adambkaplan commented

@bparees based on some of the work on https://bugzilla.redhat.com/show_bug.cgi?id=1771335 - I discovered that we have the opposite problem. If a BuildConfig has a pull secret, but the output does not have a push secret (or there is no output), we don't set up the pull secret correctly.

openshift-bot commented

Issues go stale after 90d of inactivity.

Mark the issue as fresh by commenting /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
Exclude this issue from closing by commenting /lifecycle frozen.

If this issue is safe to close now please do so with /close.

/lifecycle stale

openshift-bot commented

Stale issues rot after 30d of inactivity.

Mark the issue as fresh by commenting /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.
Exclude this issue from closing by commenting /lifecycle frozen.

If this issue is safe to close now please do so with /close.

/lifecycle rotten
/remove-lifecycle stale

openshift-bot commented

Rotten issues close after 30d of inactivity.

Reopen the issue by commenting /reopen.
Mark the issue as fresh by commenting /remove-lifecycle rotten.
Exclude this issue from closing again by commenting /lifecycle frozen.

/close

openshift-ci-robot commented

@openshift-bot: Closing this issue.

In response to this:

Rotten issues close after 30d of inactivity.

Reopen the issue by commenting /reopen.
Mark the issue as fresh by commenting /remove-lifecycle rotten.
Exclude this issue from closing again by commenting /lifecycle frozen.

/close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.