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
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.
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.
"error: username/password or bearer token may be set, but not both"
@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
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