Description of problem: oc tag not generating error for insufficient permissions. Version-Release number of selected component (if applicable): oc v3.11.88 kubernetes v1.11.0+d4cacc0 features: Basic-Auth GSSAPI Kerberos SPNEGO How reproducible: Every time Steps to Reproduce: 1. oc new-project imgtest 2. oc import-image test-img --from=registry.access.redhat.com/rhel7 --confirm 3. oc create -f - <<EOT apiVersion: authorization.openshift.io/v1 kind: Role metadata: annotations: openshift.io/description: "A user who thinks they can tag an image." openshift.io/reconcile-protect: "false" name: tag-bug-role namespace: imgtest rules: - apiGroups: - image.openshift.io attributeRestrictions: null resources: - imagestreams verbs: - update EOT 4. oc create sa tag-bug-sa 5. oc policy add-role-to-user view -z tag-bug-sa -n imgtest 6. oc policy add-role-to-user tag-bug-role -z tag-bug-sa --role-namespace=imgtest 7. TOKEN=$(oc get secret $(oc get sa tag-bug-sa -o go-template='{{(index .secrets 0).name}}') -o go-template='{{.data.token}}') 8. oc config set-credentials tag-bug-sa --token=`echo ${TOKEN} | base64 -d` 9. oc config set-context $(oc config current-context) --user=tag-bug-sa 10. oc whoami system:serviceaccount:imgtest:tag-bug-sa 11. oc tag test-img:latest test-img:v1 Tag test-img:v1 set to test-img@sha256:ea3c514078b81bf58ea76a545ed7abe60498c4f8617e571bd4947bd1ded68a8e. 12. oc get istag NAME DOCKER REF UPDATED test-img:latest registry.access.redhat.com/rhel7@sha256:ea3c514078b81bf58ea76a545ed7abe60498c4f8617e571bd4947bd1ded68a8e 5 minutes ago Actual results: It allows you to tag an image but does not show any errors or notices that the imagestream was not tagged unless you run "oc --loglevel=10 tag test-img:latest test-img:v1" Expected results: If oc tag is going to attempt to tag the image and imagestream then if the user/service account does not have imagestreamtags resource permission then it should show an error or notification upon completion of command indicating it so that customers do not get confused why the command says that it completed successfully but the "oc get istag" does not show that it was successful. Additional info: Case #: 02451875
Could reproduce this bug follow the steps in comment #0 in 4.4.0-0.nightly-2020-02-17-192940 cluster. $ oc version Client Version: 4.4.0-0.nightly-2020-02-18-005549 Kubernetes Version: v1.17.1 $ oc tag test-img:latest test-img:v1 Tag test-img:v1 set to test-img@sha256:d3c2bbd140aa9613cb6cd737adaa4c66be451569fc10180d2d44ee34625b53d1. $ oc --loglevel=10 tag test-img:latest test-img:v1 I0218 13:52:24.115847 10533 request.go:1017] Response Body: {"kind":"Status","apiVersion":"v1","metadata":{},"status":"Failure","message":"imagestreamtags.image.openshift.io \"test-img:v1\" is forbidden: User \"system:serviceaccount:imgtest:tag-bug-sa\" cannot update resource \"imagestreamtags\" in API group \"image.openshift.io\" in the namespace \"imgtest\"","reason":"Forbidden","details":{"name":"test-img:v1","group":"image.openshift.io","kind":"imagestreamtags"},"code":403}
That's OK to have this error in the log. When you don't have permissions to use imagestreamtags, oc should fallback to imagestreams. To verify this BZ, you should see two tags in the image stream after the last command.
Check oc client 4.4.0-0.nightly-2020-02-18-164016 with 4.4.0-0.nightly-2020-02-18-164016 server $oc whoami system:serviceaccount:imgtest:tag-bug-sa $oc tag test-img:latest test-img:v1 Tag test-img:v1 set to test-img@sha256:d3c2bbd140aa9613cb6cd737adaa4c66be451569fc10180d2d44ee34625b53d1. $oc get istag NAME IMAGE REFERENCE UPDATED test-img:latest registry.access.redhat.com/rhel7@sha256:d3c2bbd140aa9613cb6cd737adaa4c66be451569fc10180d2d44ee34625b53d1 5 minutes ago test-img:v1 registry.access.redhat.com/rhel7@sha256:d3c2bbd140aa9613cb6cd737adaa4c66be451569fc10180d2d44ee34625b53d1 7 seconds ago Thanks for the explain, Oleg. I could see two imagestreamtags in the last cmd, and I saw the details in the cmd log, after istag getting forbidden, api switchs to check the imagestreams. http://pastebin.test.redhat.com/837206
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2020:0581