Bug 1746149 - oc tag not generating error for insufficient permissions.
Summary: oc tag not generating error for insufficient permissions.
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: OpenShift Container Platform
Classification: Red Hat
Component: ImageStreams
Version: 3.11.0
Hardware: Unspecified
OS: Unspecified
unspecified
medium
Target Milestone: ---
: 4.4.0
Assignee: Oleg Bulatov
QA Contact: XiuJuan Wang
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2019-08-27 18:47 UTC by coberry
Modified: 2020-05-04 11:13 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Cause: oc tag didn't update imagestreams when imagestreamtags are unaccessible. Consequence: oc tag says that the new tag is created, but it doesn't. Fix: update imagestream Result: oc tag really creates the tag even if there are no permissions for imagestreamtag api.
Clone Of:
Environment:
Last Closed: 2020-05-04 11:13:08 UTC
Target Upstream Version:


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Github openshift oc pull 275 None closed Bug 1746149: fix tag creation when imagestreamtags are not accessible 2020-06-25 08:12:39 UTC
Github openshift origin pull 24505 None closed Bug 1746149: test if oc tag can work without imagestreamtags 2020-06-25 08:12:39 UTC
Red Hat Product Errata RHBA-2020:0581 None None None 2020-05-04 11:13:35 UTC

Description coberry 2019-08-27 18:47:23 UTC
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

Comment 2 XiuJuan Wang 2020-02-18 05:57:13 UTC
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}

Comment 3 Oleg Bulatov 2020-02-18 14:43:31 UTC
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.

Comment 4 XiuJuan Wang 2020-02-19 02:28:13 UTC
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

Comment 6 errata-xmlrpc 2020-05-04 11:13:08 UTC
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


Note You need to log in before you can comment on or make changes to this bug.