Open aetomala opened 4 years ago
Hi @aetomala,
Are you still experiening the same issue ?
I'm actually using the CSO 3.3.4 running on top of OpenShift and it was able to connect it my private Quay registry.
I think CSO should work well if you've correctly linked the pull-secret to the default
serviceaccount.
Hello,
I have the same issue with CSO 3.3. I'm using a private Quay registry. The credentials to access this registry are sotored at cluster level: The default registries of the cluster are modified to include the private Quay registry with credentials. So there is secret deployed in the cluster and no "imagePullSecrets" in Pod manifests. Do you think there is way to modify CSO to use this credentials ?
Another approach would be to set a secret with a token to access the registry. Can we use a secret with a mapping of registry url and token define the token to access a private registry ?
what was the solution? i'm stuck with this aswell... i have multiple organizations inside on-prem quay and therefore created all pull-secrets and linked them to sa/default inside openshift-operators namespace with no change....
btw: quaybridge operator works flawless but uses dedicated secret.
thanx
We are seeing this as well on Openshift 4.8. Fairly vanilla install and using the Quay CSO.
Now that the operator is able to talk to an on-prem Quay. see issue #30 and #28. I am running into issues authenticating with the registry. I have a pod that uses a secret. this secret is part of the pod manifest; however in the CSO pod logs I see the following:
For testing purposes, I have configured CSO to only analyze the default namespace. A CSO pod exists in the default namespace. The messages above come from that pod. Below you will see my pod yaml. In quay I created a robot-account with write permission to the repository I am pulling from. I created a secret in OS and I am using that secret as part of my pod manifest. Is there a different way that I need to define my secret and set it in my OS cluster/pod yaml combination?