Bug 2018659

hey @vkochuku,

What do you mean by a "global pullsecret" ? 

In order to pull or build using "private" images you need to have a imagePullSecret (or a secret) attached to the serviceaccount used when executing the PipelineRun. By default, in OpenShift Pipelines, that service account is the "pipeline" service account.

I don't think we can make an assumption that any PipelineRun should be able to use/pull a private image without the user providing the secret.

Cheers,
Vincent D.

Ok, @cboudjna pointed me to https://docs.openshift.com/container-platform/4.7/openshift_images/managing_images/using-image-pull-secrets.html#images-update-global-pull-secret_using-image-pull-secrets. The global pull secret is there to allow kubernetes (and in more detail kubelet / the container runtime) to download private images to be used by pods.

The trick here is that, buildah is running in a ClusterTask and thus doesn't have access to node's secret. It doesn't have any way to get the Global pullSecret as we do not "mount" pullsecret automatically in all pods managed by Tekton (running buildah in a pod is just "one case" of things you would do).

A "possible" workaround here is to, indeed, attach the "registry secret" to the pipeline SA (or the SA you are using to run you buildah task/pipeline). 

The operator could probably get the global pullsecret and attach it by default to the pipeline SA so that it is available for all Task. But security wise, I am not a huge fan of this, at it would mean that any authenticated user that can run a Pod or a Task, could have access to the registry. I feel it's better to be explicit in that case.

Hey @vdemeest, I'm the customer who raised that case.
A correctly configured OCP cluster (OKD isn't covered here) can pull any image from registry.redhat.io. So I think it's a fair expectation from users that a Buildah task should be able to reference a base image from registry.redhat.io out of the box.
As for security, Buildah tasks already run as privileged containers which is a more serious thing than attaching a pull secret to the pipeline ServiceAccount.

If this isn't fixed on the implementation, than it would mean that A)That limitation should be documented and B)Developers would need to ask a cluster admin to copy the pull secret from the 'default' Namespace or use their own Red Hat account token for their pipelines.
This is far from ideal.

Hey @benjamin.merot, 

Thank you for speaking up here :)

> A correctly configured OCP cluster (OKD isn't covered here) can pull any image from registry.redhat.io. So I think it's a fair expectation from users that a Buildah task should be able to reference a base image from registry.redhat.io out of the box.

Is it a fair expectation that Pods created in OCP can access, from the inside of the container, to registry.redhat.io, in an authenticated manner ? Buildah running in a Task is exactly that, the buildah process running into a container, and that container, doesn't have the same "access/secret" that the node have.

That said, I am not saying it's an unfair expectation, it is even probably worth exploring this as a feature ; for example, if one could label a Task or a TaskRun to "tell" the operator to automatically attach/mount the global pull secret.

> As for security, Buildah tasks already run as privileged containers which is a more serious thing than attaching a pull secret to the pipeline ServiceAccount.

The ClusterTask shipped by default with OpenShift Pipelines doesn't run as privileged (nor it needs to). It does need to run with a slightly more elevated SCC than restricted but it's not privileged, and it's also being worked on (4.10 hopefully OCP will support some part of user namespace that we will be able to use for buildah and other TaskRuns).

> A)That limitation should be documented and B)Developers would need to ask a cluster admin to copy the pull secret from the 'default' Namespace or use their own Red Hat account token for their pipelines.

Yes, this is the current workaround / "best effort", I'll create a feature request around this though (and will comment back the link here)

Feature Request for this : https://issues.redhat.com/browse/RFE-2245

Assuming (for example) we want to build (using Buildah) a new image from `registry.redhat.io/ansible-automation-platform-21/ee-minimal-rhel8:1.0.0-48`

Workaround:
1. Import the image from the remote registry into the internal OpenShift Image Registry:
~~~
$ oc import-image openshift/ee-minimal-rhel8:1.0.0-48 -n openshift --from=registry.redhat.io/ansible-automation-platform-21/ee-minimal-rhel8:1.0.0-48 --confirm 
~~~

2. Now you should be able to build your image substituting:
~~~
FROM registry.redhat.io/ansible-automation-platform-21/ee-minimal-rhel8:1.0.0-48
~~~
with:
~~~
FROM image-registry.openshift-image-registry.svc:5000/openshift/ee-minimal-rhel8:1.0.0-48
~~~

Hello Team,

Thanks for sharing the workaround. However, any plans for fixing this via Operator?

Thanks,
Vinu K