quay / container-security-operator

Identify image vulnerabilities in Kubernetes pods
Apache License 2.0
104 stars 38 forks source link

Failed to sync layer data ... 401 Unauthorized #48

Open aetomala opened 4 years ago

aetomala commented 4 years ago

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:

level=info msg="Requeued item" key=default/ssltunnel
level=debug msg="Pod updated" key=default/ssltunnel
level=info msg="Garbage collecting unreferenced ImageManifestVulns" key=default/ssltunnel
level=error msg="Failed to sync layer data" key=default/ssltunnel err="Request returned non-200 response: 401 Unauthorized"
level=info msg="Garbage collecting unreferenced ImageManifestVulns" key=default/ssltunnel
level=error msg="Failed to sync layer data" key=default/ssltunnel err="Request returned non-200 response: 401 Unauthorized"

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?

kind: Pod
metadata:
  name: example
  labels:
    app: hello-openshift
  namespace: default
spec:
  containers:
    - name: hello-openshift
      image: openshift/hello-openshift
      ports:
        - containerPort: 8080
  imagePullSecrets:
    - name: aetomala-aetomalarobot-pull-secret
abessifi commented 3 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.

Vampouille commented 3 years ago

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 ?

Vampouille commented 3 years ago

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 ?

toastbrotch commented 2 years ago

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

dsim4 commented 2 years ago

We are seeing this as well on Openshift 4.8. Fairly vanilla install and using the Quay CSO.