Bug 1790978 - Multiple credential sources being provided to oc client during prune
Summary: Multiple credential sources being provided to oc client during prune
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: OpenShift Container Platform
Classification: Red Hat
Component: oc
Version: 4.4
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
: 4.4.0
Assignee: Ricardo Maraschini
QA Contact: zhou ying
URL:
Whiteboard:
Depends On:
Blocks: 1762837 1821648
TreeView+ depends on / blocked
 
Reported: 2020-01-14 15:59 UTC by Ricardo Maraschini
Modified: 2020-05-04 11:24 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
: 1821648 (view as bug list)
Environment:
Last Closed: 2020-05-04 11:24:10 UTC
Target Upstream Version:
rmarasch: needinfo-
rmarasch: needinfo-


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Github openshift oc pull 257 None closed Bug 1790978: Zeroing BearerTokenFile for prune. 2020-07-20 14:47:51 UTC
Red Hat Product Errata RHBA-2020:0581 None None None 2020-05-04 11:24:40 UTC

Description Ricardo Maraschini 2020-01-14 15:59:22 UTC
Description of problem:

When pruning images through oc client inside the client tries to use two distinct credential sources: BasicAuth and BearerTokenFile. This apparently started to happen after a Bump on vendored client-go library, making our usage somehow incompatible.


Version-Release number of selected component (if applicable):


How reproducible: Always


Steps to Reproduce:
1. Build oc client docker image from master:
    docker build -t quay.io/rmarasch/cli -f ./images/cli/Dockerfile.rhel  .
2. Create a new project
    oc new-project rmarasch
3. Bind to default service account the "pruner" role using:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: rmarasch
subjects:
- kind: ServiceAccount
  namespace: rmarasch
  name: default
roleRef:
  kind: ClusterRole
  name: system:image-pruner

4. Deploy a pod with the image created on step 1:

apiVersion: v1
kind: Pod
metadata:
  name: cli
  labels:
    name: cli
spec:
  containers:
  - name: cli
    image: quay.io/rmarasch/cli
    command: [ "oc" ]
    args: 
      - "adm"
      - "prune"
      - "images"
      - "--prune-registry=false"
      - "--confirm"

Actual results:

Pod fails with "error: username/password or bearer token may be set, but not both"

Expected results:

Prune runs successfully.

Additional info:

It seems like the problem is the fact that we always set an username("unused"):

https://github.com/openshift/oc/blob/master/pkg/cli/admin/prune/images/images.go#L856

If we look at the way client-go validates the authentications we found this:

https://github.com/openshift/oc/blob/master/vendor/k8s.io/client-go/transport/round_trippers.go#L45

Comment 4 zhou ying 2020-01-21 10:31:52 UTC
Confirmed with the latest code , the issue has fixed, but need to add option "--force-insecure=true", will open new bug to follow the new issue. 

[zhouying@dhcp-140-138 ~]$ cat /tmp/pod.yaml 
apiVersion: v1
kind: Pod
metadata:
  name: cli
  labels:
    name: cli
spec:
  containers:
  - name: cli
    image: docker.io/zhouying7780/cli
    command: [ "oc" ]
    args: 
      - "adm"
      - "prune"
      - "images"
      - "--force-insecure=true"
      - "--prune-registry=false"
      - "--confirm"


[zhouying@dhcp-140-138 ~]$ oc create -f /tmp/pod.yaml 
pod/cli created
[zhouying@dhcp-140-138 ~]$ oc get po -w
NAME   READY   STATUS              RESTARTS   AGE
cli    0/1     ContainerCreating   0          4s
cli    0/1     ContainerCreating   0          8s
cli    0/1     ContainerCreating   0          9s
cli    0/1     Completed           0          10s
cli    0/1     Completed           1          11s
cli    0/1     CrashLoopBackOff    1          12s
cli    0/1     Completed           2          26s
cli    0/1     CrashLoopBackOff    2          39s
cli    0/1     Completed           3          53s
cli    0/1     CrashLoopBackOff    3          66s


[zhouying@dhcp-140-138 ~]$ oc logs -f po/cli
Only API objects will be removed.  No modifications to the image registry will be made.
Deleted 0 objects.

Comment 5 Ricardo Maraschini 2020-01-21 10:54:34 UTC
There is no need to open a new bug. This is happening becuase the pod created does not trust the internal registry certificate but this is expected.

To make it work without the force-insecure flag you need to mount the registry certificates and update trusted ca bundles inside the pod before running the oc command line.

Comment 9 Ivan 2020-04-07 09:32:06 UTC
"error: username/password or bearer token may be set, but not both"

Comment 10 Ricardo Maraschini 2020-04-07 10:05:27 UTC
@Ivan

I have created a specific BZ to track this on version 4.3, let's move on there.

https://bugzilla.redhat.com/show_bug.cgi?id=1821648

Comment 12 errata-xmlrpc 2020-05-04 11:24:10 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.