Bug 1790978

Summary: Multiple credential sources being provided to oc client during prune
Product: OpenShift Container Platform Reporter: Ricardo Maraschini <rmarasch>
Component: ocAssignee: Ricardo Maraschini <rmarasch>
Status: CLOSED ERRATA QA Contact: zhou ying <yinzhou>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 4.4CC: aos-bugs, icherapa, jokerman, mfojtik, scuppett, yinzhou
Target Milestone: ---Flags: rmarasch: needinfo-
rmarasch: needinfo-
Target Release: 4.4.0   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
: 1821648 (view as bug list) Environment:
Last Closed: 2020-05-04 11:24:10 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 1762837, 1821648    

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