A nit/typo:

As an aside, since we are processing this as a boolean, would it be easier to just make this a boolean flag rather than a string flag? Maybe something like --enable-psa? This way we don't have to do any if statements like this where we are processing a string into a boolean.

Somehow I missed this. No it should not be treated as a boolean. It should match what we're doing in run bundle. #6062 we treat it as an enum to match what is in operator-framework/api.

Would it be possible for the scorecard implementation to import and use the same logic that was created for operator-sdk run bundle?

I'm fine to leave this as is if we are happy with it, but it would be nice to be using the same tooling/logic in all places we want this kind of functionality rather than having slightly different methods for each implementation.

It might be possible, just seems weird. We would likely want to move the enum stuff out of run bundle into a common area so that it can be used by both sides: scorecard & run bundle.

In my testing, a bit more than this was necessary.

https://github.com/operator-framework/operator-sdk/pull/6181/files#diff-799876ec2e5aaa40d10a0e540a1cf58844df2b467fe803fac8956728bbefe6b9R73-R144

He's adding the Seccompprofile

	// SecurityContext: &corev1.PodSecurityContext{
	//     SeccompProfile: &corev1.SeccompProfile{
	//         Type: corev1.SeccompProfileTypeRuntimeDefault,
	//     },

That's what we ended up adding to the run bundle command. You shouldn't have to add the runuser to it.

When I was testing my patch, the 'scorecard-untar' init container needed the RunAsUser (the RunAsGroup may not be necessary, but I put it in there for completeness). This is needed because this container utilizes UBI directly, and UBI does not specify a user. Hence, the untar will not run. Here is the error message:

  Warning  Failed     4s (x2 over 4s)  kubelet            Error: container has runAsNonRoot and image will run as root (pod: "scorecard-test-tw6p_default(dba24b81-7d41-4941-9b4f-946e2a15a079)", container: scorecard-untar)

This is from running kubectl describe pod scorecard-test-xxxx with this patch. That's why the timeout is occurring in the e2e test. This is consistent with what I saw when testing before I put in the RunAsUser.

Maybe we should consider creating and pushing a custom image that will run as a non-root user by default?

@bcrochet I discussed with @everettraven and you are correct with the RunUser. The reason I didn't have to do it with run bundle was the index images have the proper userids. So +1 to adding your changes to this PR.

Maybe we should consider creating and pushing a custom image that will run as a non-root user by default?

My first thought was "why bother?" but then I had the thought that it might not be a bad idea to do that, and have it be based on ubi(8|9):latest so that it is kept up-to-date on every release of operator-sdk.

My first thought was "why bother?" but then I had the thought that it might not be a bad idea to do that, and have it be based on ubi(8|9):latest so that it is kept up-to-date on every release of operator-sdk.

My only reason for suggesting this was because I believe that there is a problem when setting RunAsUser on OpenShift >= 4.11.

There is this note in the sample pod security manifest in the Operator SDK Pod Security Standards docs:

# WARNING: Ensure that the image used defines an UserID in the Dockerfile
# otherwise the Pod will not run and will fail with `container has runAsNonRoot and image has non-numeric user`.
# If you want your workloads admitted in namespaces enforced with the restricted mode in OpenShift/OKD vendors
# then, you MUST ensure that the Dockerfile defines a User ID OR you MUST leave the `RunAsNonRoot` and
# RunAsUser fields empty.

Creating the custom container image that can be used by default would allow the default logic to always work without specifying RunAsUser which, as far as I understand, should make the default logic work on any cluster.

The "why bother?" was more about just one more asset to have to track. I'm totally on board with doing it though. I think it makes a lot of sense once I took a step back and thought about it.

@theishshah was there ever any decision on the direction to go in regards to creating a new container image for scorecard that will run as a non root user within the container?